Re: ProxyTimeout does not work as documented
Brian Rectanus wrote: Comments on the idea of this? I was just going to point out that it's definitely useful being able to specify separate connection and actual request timeouts. From a quick look at your diff, you already have this in mind. :) An example: with a reverse proxy, you might expect to be able to connect to a backend server on the same network within milliseconds, so a connection timeout of a couple of seconds is reasonable (give up, try the next server); but the actual response could take much longer to generate. It would be nice to have the connection timeout as a proper directive - rather than only as a parameter to ProxyPass - so that people enabling mod_proxy via other mechanisms can set it. Also so that you can set a default in one place, rather than having to repeat it in multiple ProxyPass statements. Also, the option setting stuff (from http://issues.apache.org/bugzilla/show_bug.cgi?id=11540) is already fixed in trunk (and 2.2.x branch), so you might want to base your work off that. HTH -- Stuart
Re: ProxyErrorOverride and redirects (PR 39245)
Nick Kew wrote: A redirection page is likely to include a redirected URL. In a reverse proxy situation, that may need to be rewritten. Conceivably, yes. Though I would maintain that *by default* people with reverse-proxies would want/expect all their headers retained intact. Use of ProxyErrorOverride could be a valid alternative to mod_proxy_html in that situation, couldn't it? Not sure what you mean there - ProxyErrorOverride is a directive for mod_proxy... In any case, it does not allow one to rewrite the redirect URL. The 2.2.4 behaviour is that the Location header gets retained as-is, but all other headers are stripped out - and I can't see why anyone would want that. Looks to me like a valid usage case for ProxyErrorOverride 3xx. I don't see how it would achieve what you stated above. If you do want to rewrite headers (Location or any others), the code that deals with altering the response for what are considered error pages is surely not the place to do it. -- Stuart Children http://terminus.co.uk/ -- Visit Guardian Unlimited - the UK's most popular newspaper website http://guardian.co.uk http://observer.co.uk -- The Newspaper Marketing Agency Opening Up Newspapers http://www.nmauk.co.uk -- This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group PLC Registered Office Number 1 Scott Place, Manchester M3 3GG Registered in England Number 908396
Re: ProxyErrorOverride and redirects (PR 39245)
Hi Plüm wrote: I guess what Nick is talking about is the body of a redirect response. A redirect response is often accompanied by a small HTML page that also contains the redirect target as a hyperlink in the case that your client does not understand the Location header. While ProxyPassReverse takes care of adjusting the Location header nobody takes care of adjusting the HTML body of the response with the wrong link. This could be fixed by an ErrorDocument for 30x response codes. IMHO only in a static matter. OK, that makes sense - I can see a usage for that. Though if that was what I was trying to achieve, I still wouldn't want it removing all my other headers (which is what happens as a result of going through the ErrorDocument processing) - so ProxyErrorOverride/ErrorDocument still seems like the wrong tool for the job. A module with an output filter that modifies the URLs within the body for redirect responses would be a better option (maybe as part of mod_prox_http). Cheers -- Stuart Children http://terminus.co.uk/ -- Visit Guardian Unlimited - the UK's most popular newspaper website http://guardian.co.uk http://observer.co.uk -- The Newspaper Marketing Agency Opening Up Newspapers http://www.nmauk.co.uk -- This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group PLC Registered Office Number 1 Scott Place, Manchester M3 3GG Registered in England Number 908396
Re: ProxyErrorOverride and redirects (PR 39245)
On Wed, Apr 04, 2007 at 10:48:58AM -0400, Eric Covener wrote: There's a simple patch attached to the report which tells httpd to keep its hands off ap_is_HTTPD_REDIRECT e.g. 3xx. Given the description of ProxyErrorOverride I wouldn't think expectations would be that 3xx responses would be overridden. That's my expectation too. Whatever people argue, I've shown in this comment: http://issues.apache.org/bugzilla/show_bug.cgi?id=39245#c11 that it's a change in behaviour since 2.0.x. The actual patch on the report might be out of date for trunk. Try the ones on http://issues.apache.org/bugzilla/show_bug.cgi?id=41601 (which I filed but closed as a dupe of the above). Though I've not checked them recently. They're making the same change. I had been meaning to chase this (and the two other bugs I found in this area of code whilst investigating - see later comments in the report). Unfortunately I'm about to go on holiday for three weeks and shall be staying far away from computers! Happy to help when I'm back though. Regards -- Stuart Children http://terminus.co.uk/
Re: ProxyErrorOverride and redirects (PR 39245)
On Wed, Apr 04, 2007 at 04:30:31PM +0100, Nick Kew wrote:
Hmmm, I have some recollection of debating this before,
Yes, in the comments of the bug the OP linked.
presumably without reaching any consensus for change.
Well no-one's refuted (or replied to in any fashion) my last posts in
bugzilla.
-if (conf-error_override == 0 ||
ap_is_HTTP_SUCCESS(r-status)) {
+if (conf-error_override == 0 ||
ap_is_HTTP_SUCCESS(r-status) || ap_is_HTTP_REDIRECT(r-status)) {
I don't think we could accept that, because it breaks existing
behaviour someone might be relying on.
Behaviour *has already been broken* from 2.0.x to 2.2.x - I've given
evidence of this. Our work systems heavily rely on the 2.0 behaviour.
Maybe someone else would like to repeat my tests - it's possible
it's not as simple as I think. Checking the 1.3.x behaviour would be
interesting too.
Without any evidence to the contrary though, I'd really appeal for the
patch to be applied.
Whatever happens, the documentation should be clarified. But to my mind
there is no doubt that I would not expect a redirect (or Not Modified
for that matter) to be considered an error.
Cheers
--
Stuart
Re: ProxyErrorOverride and redirects (PR 39245)
On Wed, Apr 04, 2007 at 10:40:27PM +0100, Nick Kew wrote: Whatever happens, the documentation should be clarified. But to my mind there is no doubt that I would not expect a redirect (or Not Modified for that matter) to be considered an error. The semantics of Error here are the same as in ErrorDocument (which is, after all, what you're invoking with ProxyErrorOverride). Absolutely. Only if I RTFM: http://httpd.apache.org/docs/2.2/mod/core.html#errordocument it says In the event of a problem or error. So what's wrong with what I've said? I take problem/error to not include 3xx responses. If you disagree then the documentation would appear to not be clear enough to one or other of us. Given it does not explicitly indicate behaviour in this particular matter, we should look at what the code does; which _was_ not to treat them as errors... until someone made a change at which point it broke peoples' assumptions/environments and caused them to file bugs. -- Stuart
Re: svn commit: r507955 - /httpd/httpd/branches/2.0.x/STATUS
William A. Rowe, Jr. wrote: -1 as is, Jim would you -please- post the actual patch you are asking us to vote on :-? (veto removal automatic upon availability of the link to the specific patch you plan to commit that actually applies, and probably my review pretty quickly, too.) Trunk patch should apply with offset, but to help things along here's a freshly generated patch against current 2.2.x HEAD (and attached to bug): http://issues.apache.org/bugzilla/attachment.cgi?id=19602 Obviously Jim has to confirm that's what he intends to apply. Thanks for the movement on this! -- Stuart Children http://terminus.co.uk/
Re: AW: svn commit: r507955 - /httpd/httpd/branches/2.0.x/STATUS
Plüm wrote: It applies to 2.2.x, but this is about 2.0.x where the trunk version does NOT work cleanly. Ah, whoops - I didn't notice this thread was 2.0 and the other 2.2. My mistake. Indeed, 2.2.x and trunk have an additional configuration directive over 2.0.x (proxy_status) which is what's getting in the way. Here's a patch for current 2.0.x: http://issues.apache.org/bugzilla/attachment.cgi?id=19606 Thanks -- Stuart Children http://terminus.co.uk/
Re: PR 37145
Ruediger Pluem wrote: Just a short reminder. I just got the 3rd duplicate for PR37145 ( data loss with httpd-2.0.55 reverse proxy method=post) and I remember myself that there had been additional cases that had been reported on the list. Well, I've posted about PR37402 which is also to revert mod_proxy behaviour broken by the changes in 2.0.55 - in this case POST *sub-requests*. It's a different situation to your bug. PatchAvailable... but I've had no feedback so I can't say what people think about it - only that it's working fine on our production servers (which do a total of around 4 million page impressions a day). The patch is currently missing one vote for backport to 2.0.x. I know that 2.0.56 may be far off, but I just hit the drums because I want to ensure that it gets in. I remember that OtherBill tended to be positive about the patch and Joe agreed with the analysis + it is already part of 2.2.0 - The best Apache HTTP Server available. So to the ballot please :-). Sorry to thread hijack, but I would really appreciate it if someone could either take some action on the above (and PR11540 come to that, which is pretty trivial) - or to give me some advice on how to get people interested. A good first step would be getting the patches into the trunk I guess. Should I come into IRC and get a sponsor? Or more testers before it's considered perhaps? Just continue to plug away on here? Are there particular people who do mod_proxy development that I might approach? Many thanks -- Stuart Children http://terminus.co.uk/
Re: [PATCHES PR 11540 PR 37402]
To start off, congratulations to all involved with 2.2.0 - especially all the coders. Now the release is done, I'd really like to get the below in for 2.2.1. Other than posting here, is there anything I can do to create some action? Who do I need to get approval from before someone can commit the patches? TIA Stuart Children wrote: Hope it's OK to lump these into one mail. They're both regarding mod_proxy, so I guess that's an excuse. Anyway, was hoping to get some movement, or at least feedback on these. They've been in bugzilla with patches for a while now. The first is http://issues.apache.org/bugzilla/show_bug.cgi?id=11540 - a pretty straightforward fix to the config merging code. Without this the ProxyTimeout (and I think some other) directive(s) don't have any effect. Which is confusing, and frustrating when the code otherwise works! The second is http://issues.apache.org/bugzilla/show_bug.cgi?id=37402 - which is to make mod_proxy allow for POST subrequests again. Slightly more controversial I guess, but going back to 2.0.54 behaviour which it doesn't appear there was an issue with. I posted to this list for discussion on this item before and didn't receive any negative comments. I guess I can't argue these are release blockers given the lack of other people complaining about them, but for the record I'd like to see both in 2.2 (as well as back-ported to 2.0 in due course). Regards -- Stuart Children http://terminus.co.uk/
POST subrequests
Hi all
Whilst testing 2.0.55 we found that some of the changes to mod_proxy has
prevented one of our custom modules from working correctly. The problem
is not with the main purpose of the CL/TE security fixes, but a related
behaviour change that's happened along the way. Specifically, in
proxy_http.c:ap_proxy_http_request(), this:
if (r-main) {
[some lines snipped]
/* If you POST to a page that gets server-side parsed
* by mod_include, and the parsing results in a reverse
* proxy call, the proxied request will be a GET, but
* its request_rec will have inherited the Content-Length
* of the original request (the POST for the enclosing
* page). We can't send the original POST's request body
* as part of the proxied subrequest, so we need to avoid
* sending the corresponding content length. Otherwise,
* the server to which we're proxying will sit there
* forever, waiting for a request body that will never
* arrive.
*/
if ((r-method_number == M_GET) headers_in[counter].key
!apr_strnatcasecmp(headers_in[counter].key,
Content-Length)) {
continue;
}
has been replaced with:
/* sub-requests never use keepalives, and mustn't pass request bodies.
* Because the new logic looks at input_brigade, we will self-terminate
* input_brigade and jump past all of the request body logic...
* Reading anything with ap_get_brigade is likely to consume the
* main request's body or read beyond EOS - which would be unplesant.
*/
if (r-main) {
p_conn-close++;
if (old_cl_val) {
old_cl_val = NULL;
apr_table_unset(r-headers_in, Content-Length);
}
if (old_te_val) {
old_te_val = NULL;
apr_table_unset(r-headers_in, Transfer-Encoding);
}
rb_method = RB_STREAM_CL;
e = apr_bucket_eos_create(input_brigade-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(input_brigade, e);
goto skip_body;
}
So in =2.0.54 the CL header was not passed on for subrequests if it was
set and the request is a GET. Now both CL and TE are removed for *all*
subrequests, regardless of the HTTP method.
As you've probably guessed, in our module we turn [some] subrequests
into POSTs. (We then set an appropriate CL header and add an input
filter to the subrequest which generates the request body.) I've written
a simple patch which adds a check on the request method again (simply
skipping most of the above lines if it's a POST). However, the comment
sub-requests ... mustn't pass request bodies made me think perhaps
some discussion is required before I stick that in bugzilla. Is there a
reason behind the musn't? Ie: are POST subrequests a problem (assuming
there's a valid input_brigade to read and a corresponding CL)?
Some googling turns up a previous thread which touches on this issue:
http://marc.theaimsgroup.com/?l=apache-httpd-devm=111099194601082w=2
As a side comment, the original check wouldn't be necessary if we knew
that the subrequest was well formed. The 2.0.54 code is there because
mod_include creates the subrequests as GETs, but leaves an invalid CL
header (in fact, it's using the main request's headers table - not a
copy). This probably applies to the other headers that mod_proxy ignores
as well.
TIA
--
Stuart Children
http://terminus.co.uk/
