You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Tom Wells <dr...@gmail.com> on 2008/09/30 15:50:00 UTC
[users@httpd] Mod_Proxy and 100-Continue
Hi Group
I'm fairly confident I've found a bug in mod_proxy in Apache 2.2.9 but
would like your opinion before I log anything to the bug tracker. It's
something I discovered while working in mod_python, but I've managed
to get it occurring with a bare-bones Apache 2.2.9 setup using only
mod_proxy and mod_headers:
This is my vhost configuration:
ProxyRequests Off
<Proxy *>
Order Deny,Allow
Allow from all
</Proxy>
<VirtualHost *:80>
ServerName munchkin.synthesis.co.za
Header add Set-Cookie "MOD_PROXY_FOOD=FOO;" early
Header add Set-Cookie "MOD_PROXY_KEEP=BAR;"
<Location /sonik/>
ProxyPass http://192.168.16.225:8118/sonik/
</Location>
ErrorLog /home/tom/dev/apache/deploy/logs/error.log
LogLevel notice
CustomLog /home/tom/dev/apache/deploy/logs/access.log combined
</VirtualHost>
The config above is forwarding requests to /sonik/ to another host
after setting two cookies, one early and one late. I am no Apache
guru, but as I understand it the early cookie is set before handlers
are processed (i.e. before modproxy kicks in) and the late will be
appended to the response after modproxy has done it's processing and
produced a complete response. Also (as far as I understand) modproxy
should try to preserve any headers already set before processing by
merging the headers before and after processing (especially any
Set-Cookie headers).
So in general this works as expected, with both cookies being returned
to the caller for regular GET and POST requests. However the problem
I've noticed is where the request contains an "Expect:100-Continue",
that the early cookie is discarded by modproxy. After some further
investigation the root problem appears that modproxy doesn't handle
the "HTTP/1.1 100 Continue\r\n\r\n" within the response from the
back-end host nicely when performing the merging of headers. I
discovered this by writing back both of these responses from the
back-end host:
"HTTP/1.1 200 OK
Content-Length: 1
"
And
"HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Content-Length: 1
"
The first response produces a final response to the client which
contains both Set-Cookie headers, and the second response produces a
final response to the client which contains only the late Set-Cookie
header.
Maybe this is normal modproxy behaviour, I can't be certain, but
reading through some of mod_proxy_http.c seems to show that this is
the intention. However I was able to test this on another Apache
instance running 2.2.4 and modproxy retains both cookies in both
cases. So either this is a bug in 2.2.9 or it's a bug that was fixed
since 2.2.4.
Your thoughts?
Thanks,
Tom
--
http://www.tomwells.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Mod_Proxy and 100-Continue
Posted by Tom Wells <dr...@gmail.com>.
On Tue, Sep 30, 2008 at 1:48 PM, Nick Kew <ni...@webthing.com> wrote:
> That's section 8.2.3 of RFC2616. But anyway, I don't see why
> use the early keyword.
As mentioned earlier, I'm not actually using mod_headers or the early
keyword at all, I was using it to demonstrate the issue with
mod_proxy. The issue is that modproxy doesn't merge headers_out with
the proxy response from the backend correctly in the 100-Continue
situation, setting an early cookie using mod_headers was how I was
able to reproduce the problem without using mod_python, so that we
could strike it off the blame-list.
I still think it's a bug - mod_proxy must have a requirement somewhere
which says "merge headers from the backend response with the headers
that were set before the request was made", because this is what it
does in the general case. If modproxy didn't have this requirement it
wouldn't even attempt it, because I can understand it's not an easy
feat. But the fact remains that modproxy doesn't work like this 100%
of the time, and in my opinion screws up when it gets a "100 Continue"
response from the back-end. I call fishy! :)
Thanks!
Tom
--
http://www.tomwells.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Mod_Proxy and 100-Continue
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 30 Sep 2008 12:00:56 -0400
"Tom Wells" <dr...@gmail.com> wrote:
> Maybe it's not a bug, but it certainly is inconsistent - and certainly
> something has has changed between the versions - so I wanted to
> highlight this.
You're right. Sorry if I came across a bit grumpy.
Anyway, I think that change will have come between 2.2.6 and 2.2.7.
> In the meantime however we have worked around this
:-)
> issue by stripping the "Expect: 100-Continue" from any inbound POSTs
> before the request is processed by modproxy. This works OK as I assume
> our clients don't really care about the "HTTP/1.1 100 Continue" before
> sending their POST body - but we have tested this only with a C# .NET
> client.
That's section 8.2.3 of RFC2616. But anyway, I don't see why
use the early keyword.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Mod_Proxy and 100-Continue
Posted by Tom Wells <dr...@gmail.com>.
On Tue, Sep 30, 2008 at 11:00 AM, Nick Kew <ni...@webthing.com> wrote:
> On Tue, 30 Sep 2008 09:50:00 -0400
> "Tom Wells" <dr...@gmail.com> wrote:
>
>
> The "early" keyword exists to help developers simulate
> a request, for example when debugging a new module.
> Perhaps it should've remained undocumented.
Exactly - and I've used it for debugging!
Maybe I should have explained my real situation which sent me down
this road, I know this is a busy list so I didn't want to bore people
:) I've developed a mod_python module which hooks into the authen and
authz Apache handlers in order to provide a common authentication and
security module in front of a set of back-end webservers. So requests
come into the Apache machine, my handlers do some fancy cookie
checking and updating and either allow the request to continue
processing (and onto the back-end webserver via modproxy) or respond
with a redirect (to get rid of a not logged in user, or a bad cookie
or whatever). This means we have a single "logical" session and
multiple disparate webservers in the back, which is nice.
So in the "real" app I don't actually use mod_header for anything, I
just used it to demonstrate the issue I was having with mod_proxy (and
thus remove any 3rd party dependencies such as mod_python and my
custom module from the mix). In my "real" app I set the Set-Cookie
header within a mod_python structure called req.headers_out, which
marshals to the Apache r->headers_out structure. Sorry to cause any
confusion here.
> HTTP has no provision for a proxy to set an end-to-end header
> such as Set-Cookie - only how it should deal with headers set by
> the backend. mod_headers isn't part of the protocol implementation;
> it's a convenience for users who want to change the default behaviour.
Ok I understand this - but modproxy does seem to provide this
behaviour, which is great, but differs between 2.2.4 and 2.2.9 when
dealing with 100-Continue responses.
> But it's not a bug now, nor was it before. If you want to set
> a header with predictable behaviour, don't use "early".
Maybe it's not a bug, but it certainly is inconsistent - and certainly
something has has changed between the versions - so I wanted to
highlight this. In the meantime however we have worked around this
issue by stripping the "Expect: 100-Continue" from any inbound POSTs
before the request is processed by modproxy. This works OK as I assume
our clients don't really care about the "HTTP/1.1 100 Continue" before
sending their POST body - but we have tested this only with a C# .NET
client.
--
http://www.tomwells.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Mod_Proxy and 100-Continue
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 30 Sep 2008 09:50:00 -0400
"Tom Wells" <dr...@gmail.com> wrote:
> ServerName munchkin.synthesis.co.za
> Header add Set-Cookie "MOD_PROXY_FOOD=FOO;" early
Why?
The "early" keyword exists to help developers simulate
a request, for example when debugging a new module.
Perhaps it should've remained undocumented.
> Also (as far as I understand) modproxy
> should try to preserve any headers already set before processing by
> merging the headers before and after processing (especially any
> Set-Cookie headers).
HTTP has no provision for a proxy to set an end-to-end header
such as Set-Cookie - only how it should deal with headers set by
the backend. mod_headers isn't part of the protocol implementation;
it's a convenience for users who want to change the default behaviour.
> Maybe this is normal modproxy behaviour, I can't be certain, but
> reading through some of mod_proxy_http.c seems to show that this is
> the intention. However I was able to test this on another Apache
> instance running 2.2.4 and modproxy retains both cookies in both
> cases. So either this is a bug in 2.2.9 or it's a bug that was fixed
> since 2.2.4.
It's probably a side-effect of fixing
https://issues.apache.org/bugzilla/show_bug.cgi?id=16518
and associated improvements.
But it's not a bug now, nor was it before. If you want to set
a header with predictable behaviour, don't use "early".
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org