Poul-Henning,<br><br>I think I managed to get this working, without needing a modification on the varnish source. Here's a snippet of the important parts of how I implemented this. (I left out all of my error checking for readability) <br>
<br><span style="font-family: courier new,monospace;">void get_req_body(struct sess *sp)</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">{</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> /* create a new shared memory file to store the request body in.</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> * Make sure this is deleted after we're done or this will eat up memory!</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> */</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> int memfd = shm_open(pidstr, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> // read the body from the client HTTP connection, </span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> int rsize = read(sp->htc->fd, body, content_length);</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> // write the body into shm</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> int wsize = write(memfd, body, content_length);</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> // seek the file descriptor back to the beginning of the file</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> lseek(memfd, 0, SEEK_SET);</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> /* set Varnish's HTTP file descriptor to this new shm file.</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> * This fools varnish into reading the request body </span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> * later on when passing it to the backend</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> *</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> * Not sure WHY this works though... If it needs to write</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> * to the client during vcl_deliver, wouldn't it just </span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> * write the contents to this shm file? It must be a </span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> * different file descriptor for writing?</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> */</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> sp->htc->fd = memfd;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">}</span><br style="font-family: courier new,monospace;"><br>This method was sort of my last ditch effort, and I was surprised that it worked. I couldn't find exactly where the deliver code writes to the socket, but the only explanation is that there is a separate socket for writing to the client. Is that correct?<br>
<br>Also, I'm not an expert on how licenses work -- if I want to distribute this, do I need to license it the same as varnish if I include your headers?<br><br>Thanks!<br><br>--Cal<br><br><br><div class="gmail_quote">
On Fri, Jan 1, 2010 at 2:02 PM, Cal Heldenbrand <span dir="ltr"><<a href="mailto:cal@fbsdata.com">cal@fbsdata.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
How difficult do you think it would be to provide this to the VRT level? I'd be happy to do the coding if you point me in the right direction of where the post data is handled in the source.<br><br>I think it would be a useful tool for the rest of the community as well. (I remember some mailing list post on doing security matching, similar to Apache's mod_security)<br>
<br>Thanks, and happy hangover day!<br><font color="#888888"><br>--Cal</font><div><div></div><div class="h5"><br><br><br><div class="gmail_quote">On Fri, Jan 1, 2010 at 5:18 AM, Poul-Henning Kamp <span dir="ltr"><<a href="mailto:phk@phk.freebsd.dk" target="_blank">phk@phk.freebsd.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In message <<a href="mailto:6d0f643a0912311432v1e594e5cl601f1a5b19b59956@mail.gmail.com" target="_blank">6d0f643a0912311432v1e594e5cl601f1a5b19b59956@mail.gmail.com</a>>, Cal H<br>
<div>eldenbrand writes:<br>
<br>
>I just started experimenting with the coolness of using inline C in VCL, and<br>
>I've run into a bit of a hurdle -- I can't find any VRT functions that allow<br>
>me to dig into the request body where the post data is at.<br>
<br>
</div>The post data is not available at any point near VCL, it is transferred<br>
to the backend as part of the backend fetch.<br>
<br>
Poul-Henning<br>
<br>
PS: Happy NewYear<br>
<font color="#888888"><br>
--<br>
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20<br>
phk@FreeBSD.ORG | TCP/IP since RFC 956<br>
FreeBSD committer | BSD since 4.3-tahoe<br>
Never attribute to malice what can adequately be explained by incompetence.<br>
</font></blockquote></div><br><br clear="all"><br>
</div></div></blockquote></div><br><br clear="all"><br>