Filter function is called three times
Hi all,
I'm just trying to write my first Module (actually a filter) for Apache and
made an observation I can't explain.
I have now made an empty skeleton that has some dummy configuration and
a callback function for my filter that I registered as follows:
static void register_hooks(apr_pool_t *p)
{
ap_register_input_filter(tvdldapfilter_name, insert_ldap_headers, NULL,
AP_FTYPE_CONTENT_SET);
}
The callback function itself has at the moment no functionality apart from
reading the dummy config and some logging.
I compiled the whole stuff, tested it with apache and it works fine. The only
thing is: according to my logs my filter is called three times (twice with
mode == AP_MODE_READBYTES and once with some other mode). The test page I call
is a simple html-Page with no pictures or additional stuff. Actually it's a
copy from the It-Works!-page.
Finally my question: What could be the reason why my filter is called three
times instead of once and is there something I could do about that?
Thanks for any hint
Sven
Problems on Suse
Hello all, We've written a simple module that reads a POST request and sends it through a socket to our server. It's been developed in Debian and works fine in three different machines. The problem is our client demanded us to deploy on Suse 10.2, and I've set up the whole thing, but, when it came to the apache module, it's behaving very weird. I've checked all the Apache configurations and they match the Debian setup, I've also recompiled it in the deploy machine (just in case), still it won't work. When it reaches this line: ret = ap_get_brigade(r-input_filters, bbin, AP_MODE_GETLINE, APR_BLOCK_READ, 0); Apache tells us in error_log: [Tue Oct 09 09:04:42 2007] [crit] [Tue Oct 09 09:04:42 2007] file http_filters.c, line 346, assertion readbytes 0 failed [Tue Oct 09 09:04:43 2007] [notice] child pid 13508 exit signal Aborted (6) and it cuts communications all of the sudden. Can anyone help me ? Thanks, Deodoro Filho
Re: Problems on Suse
On Tue, 09 Oct 2007 14:54:27 -0300 Deodoro Filho [EMAIL PROTECTED] wrote: Can anyone help me ? Looks like the SuSE is compiled with debug, and is unhappy about you passing 0 for readbytes. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: svn commit: r583002 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c
On 10/09/2007 01:47 AM, [EMAIL PROTECTED] wrote: Author: niq Date: Mon Oct 8 16:47:35 2007 New Revision: 583002 URL: http://svn.apache.org/viewvc?rev=583002view=rev Log: mod_proxy_http: Don't unescape/escape forward proxied URLs. Just check them. PR 42592 also add fix to PR42572 to CHANGES (from r563487/r563489) Modified: httpd/httpd/trunk/CHANGES httpd/httpd/trunk/modules/proxy/mod_proxy_http.c Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_http.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_http.c?rev=583002r1=583001r2=583002view=diff == --- httpd/httpd/trunk/modules/proxy/mod_proxy_http.c (original) +++ httpd/httpd/trunk/modules/proxy/mod_proxy_http.c Mon Oct 8 16:47:35 2007 @@ -36,6 +36,9 @@ const char *err; const char *scheme; apr_port_t port, def_port; +const char *p; +const char *allowed = ~$-_.+!*'(),;:@=/; /* allowed+reserved from + ap_proxy_canonenc */ *allowed could be made 'static'. Otherwise looks good. Regards Rüdiger
Re: Error from DSOLoadLibrary in Apache2.0.61(64 bit) on AIX 5.3(64 bit)
On 10/9/07, Renu Tiwari [EMAIL PROTECTED] wrote: We are facing an issue in dynamically loading the thirdparty module to Apache2.0.61 server. Error shown in error_logs of Apache server is *Error from DSOLoadLibrary - Not enough space.* That's not an Apache message, FWIW. I can't find a reference to DSOLoadLibrary. googling indicates that some symbol table might be full and maybe some other ld options need to be used (something about big table of contents -- ld flag bigtoc) See if there is a LDR_CNTRL setting in bin/envvars. If there is one (I don't think there should be one for 64-bit), comment it out to confirm that it doesn't hurt this. Call AIX support. Work with AIX folks that help ISVs.
AP_CONN_CLOSE on force-response-1.0
I believe the line making the connection always 'AP_CONN_CLOSE' on
force-response-1.0 is a erroneous leftover. The 1.0 should keep the connection
alive if the browser will ask it to do so.
httpd-trunk/modules/http$ grep -n -C 3 force-response-1.0 http_filters.c
...
700:/* kludge around broken browsers when indicated by
force-response-1.0 701- */
702-if (r-proto_num == HTTP_VERSION(1,0)
703: apr_table_get(r-subprocess_env, force-response-1.0)) {
704-*protocol = HTTP/1.0;
705-r-connection-keepalive = AP_CONN_CLOSE;
^
706-}
...
Re: svn commit: r583002 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c
On Oct 9, 2007, at 5:33 AM, Ruediger Pluem wrote: On 10/09/2007 01:47 AM, [EMAIL PROTECTED] wrote: Author: niq Date: Mon Oct 8 16:47:35 2007 New Revision: 583002 URL: http://svn.apache.org/viewvc?rev=583002view=rev Log: mod_proxy_http: Don't unescape/escape forward proxied URLs. Just check them. PR 42592 also add fix to PR42572 to CHANGES (from r563487/r563489) Modified: httpd/httpd/trunk/CHANGES httpd/httpd/trunk/modules/proxy/mod_proxy_http.c Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_http.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/ mod_proxy_http.c?rev=583002r1=583001r2=583002view=diff = = --- httpd/httpd/trunk/modules/proxy/mod_proxy_http.c (original) +++ httpd/httpd/trunk/modules/proxy/mod_proxy_http.c Mon Oct 8 16:47:35 2007 @@ -36,6 +36,9 @@ const char *err; const char *scheme; apr_port_t port, def_port; +const char *p; +const char *allowed = ~$-_.+!*'(),;:@=/; /* allowed +reserved from + ap_proxy_canonenc */ *allowed could be made 'static'. Otherwise looks good. Would almost make sense to have this as an API function... anyone have issues if I make the required adjustments for that to happen?
RE: Error from DSOLoadLibrary in Apache2.0.61(64 bit) on AIX 5.3(64 bit)
Hi Thanks for the reply. Just wanted to confirm one thing. We have build the apache 2.0.61 source on AIX 5.2(64 bit) and than placed the resultant Apache folder structure to AIX5.3(64 bit) m/c. Can this cause some kind of discrepencies? Thanx From: Jeff Trawick [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 09, 2007 4:42 PM To: dev@httpd.apache.org Subject: Re: Error from DSOLoadLibrary in Apache2.0.61(64 bit) on AIX 5.3(64 bit) On 10/9/07, Renu Tiwari [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: We are facing an issue in dynamically loading the thirdparty module to Apache2.0.61 server. Error shown in error_logs of Apache server is Error from DSOLoadLibrary - Not enough space. That's not an Apache message, FWIW. I can't find a reference to DSOLoadLibrary. googling indicates that some symbol table might be full and maybe some other ld options need to be used (something about big table of contents -- ld flag bigtoc) See if there is a LDR_CNTRL setting in bin/envvars. If there is one (I don't think there should be one for 64-bit), comment it out to confirm that it doesn't hurt this. Call AIX support. Work with AIX folks that help ISVs. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
Re: Error from DSOLoadLibrary in Apache2.0.61(64 bit) on AIX 5.3(64 bit)
On 10/9/07, Renu Tiwari [EMAIL PROTECTED] wrote: Hi Thanks for the reply. Just wanted to confirm one thing. We have build the apache 2.0.61 source on AIX 5.2(64 bit) and than placed the resultant Apache folder structure to AIX5.3(64 bit) m/c. Can this cause some kind of discrepencies? It shouldn't ;)
Re: svn commit: r583002 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c
On Tue, 9 Oct 2007 09:03:59 -0400 Jim Jagielski [EMAIL PROTECTED] wrote: Would almost make sense to have this as an API function... anyone have issues if I make the required adjustments for that to happen? What's the scope of your proposed API function? The current http_proxy_canonenc, generalised to serve also for balancer_proxy_canonenc, ajp_proxy_canonenc, etc? If so, sounds good to me. The thought had crossed my mind, but is a definite Not Yet on my to-do list. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: AP_CONN_CLOSE on force-response-1.0
On Tue, 9 Oct 2007 16:54:21 +0400
Aleksey Midenkov [EMAIL PROTECTED] wrote:
I believe the line making the connection always 'AP_CONN_CLOSE' on
force-response-1.0 is a erroneous leftover. The 1.0 should keep the
connection alive if the browser will ask it to do so.
httpd-trunk/modules/http$ grep -n -C 3 force-response-1.0
http_filters.c ...
700:/* kludge around broken browsers when indicated by
force-response-1.0 701- */
702-if (r-proto_num == HTTP_VERSION(1,0)
703: apr_table_get(r-subprocess_env,
force-response-1.0)) { 704-*protocol = HTTP/1.0;
705-r-connection-keepalive = AP_CONN_CLOSE;
^
706-}
...
Have you verified what happens if you remove that line?
Does it then respect exactly what the client asked for
if there's a Connection: header in the request?
And what does it then do if there isn't one?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: svn commit: r583002 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c
Jim Jagielski wrote: On Oct 9, 2007, at 5:33 AM, Ruediger Pluem wrote: +const char *allowed = ~$-_.+!*'(),;:@=/; /* allowed+reserved from + ap_proxy_canonenc */ Otherwise looks good. Would almost make sense to have this as an API function... anyone have issues if I make the required adjustments for that to happen? Uhm - isn't this what uri_delims is for??? Bill
Re: AP_CONN_CLOSE on force-response-1.0
On Tuesday 09 October 2007 18:13:00 Nick Kew wrote:
On Tue, 9 Oct 2007 16:54:21 +0400
Aleksey Midenkov [EMAIL PROTECTED] wrote:
I believe the line making the connection always 'AP_CONN_CLOSE' on
force-response-1.0 is a erroneous leftover. The 1.0 should keep the
connection alive if the browser will ask it to do so.
httpd-trunk/modules/http$ grep -n -C 3 force-response-1.0
http_filters.c ...
700:/* kludge around broken browsers when indicated by
force-response-1.0 701- */
702-if (r-proto_num == HTTP_VERSION(1,0)
703: apr_table_get(r-subprocess_env,
force-response-1.0)) { 704-*protocol = HTTP/1.0;
705-r-connection-keepalive = AP_CONN_CLOSE;
^
706-}
...
Have you verified what happens if you remove that line?
Does it then respect exactly what the client asked for
if there's a Connection: header in the request?
And what does it then do if there isn't one?
Yes, I have checked all 6 variants. In case 'Connection:' header is in the
request, the response is sent exactly how this header asks (for both 1.0 and
1.1 protocols). In case of absence of 'Connection:' header, the response for
1.0 answers with 'Connection: close' and closes the connection. The response
for 1.1 does not have 'Connection:' header, but keeps the connection open.
The logic is provided by ap_set_keepalive, it is called right after
basic_http_header_check in ap_http_header_filter. I believe the absence of
the header in the last variant does regard RFC2616 (as 19.6.2 states).
Re: svn commit: r583002 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c
On Oct 9, 2007, at 10:58 AM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: On Oct 9, 2007, at 5:33 AM, Ruediger Pluem wrote: +const char *allowed = ~$-_.+!*'(),;:@=/; /* allowed +reserved from + ap_proxy_canonenc */ Otherwise looks good. Would almost make sense to have this as an API function... anyone have issues if I make the required adjustments for that to happen? Uhm - isn't this what uri_delims is for??? We're not looking for deliminators, we're looking for invalid chars in a URL. So something like ap_proxy_validurl() or ap_proxy_good_encoding()... I can think of a few places where we'd want to replicate and reuse this...
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 9, 2007, at 11:04 AM, Aleksey Midenkov wrote:
On Tuesday 09 October 2007 18:13:00 Nick Kew wrote:
On Tue, 9 Oct 2007 16:54:21 +0400
Aleksey Midenkov [EMAIL PROTECTED] wrote:
I believe the line making the connection always 'AP_CONN_CLOSE' on
force-response-1.0 is a erroneous leftover. The 1.0 should keep the
connection alive if the browser will ask it to do so.
httpd-trunk/modules/http$ grep -n -C 3 force-response-1.0
http_filters.c ...
700:/* kludge around broken browsers when indicated by
force-response-1.0 701- */
702-if (r-proto_num == HTTP_VERSION(1,0)
703: apr_table_get(r-subprocess_env,
force-response-1.0)) { 704-*protocol = HTTP/1.0;
705-r-connection-keepalive = AP_CONN_CLOSE;
^
706-}
...
Have you verified what happens if you remove that line?
Does it then respect exactly what the client asked for
if there's a Connection: header in the request?
And what does it then do if there isn't one?
Yes, I have checked all 6 variants. In case 'Connection:' header is
in the
request, the response is sent exactly how this header asks (for
both 1.0 and
1.1 protocols). In case of absence of 'Connection:' header, the
response for
1.0 answers with 'Connection: close' and closes the connection. The
response
for 1.1 does not have 'Connection:' header, but keeps the
connection open.
The logic is provided by ap_set_keepalive, it is called right after
basic_http_header_check in ap_http_header_filter. I believe the
absence of
the header in the last variant does regard RFC2616 (as 19.6.2 states).
I might be confused here, but if the response is forced 1.0,
then there are no keepalives in which case we want to *force*
keepalives off.
Re: AP_CONN_CLOSE on force-response-1.0
Jim Jagielski wrote: I might be confused here, but if the response is forced 1.0, then there are no keepalives in which case we want to *force* keepalives off. Actually two different settings, no? 1.0 supported explicit keepalives.
Re: AP_CONN_CLOSE on force-response-1.0
On Tue, 9 Oct 2007 19:04:22 +0400 Aleksey Midenkov [EMAIL PROTECTED] wrote: Yes, I have checked all 6 variants. Nice - thanks. In case 'Connection:' header is in the request, the response is sent exactly how this header asks (for both 1.0 and 1.1 protocols). In case of absence of 'Connection:' header, the response for 1.0 answers with 'Connection: close' and closes the connection. The response for 1.1 does not have 'Connection:' header, but keeps the connection open. OK, that last case is the one that risks biting us: if someone has asked the server to force a 1.0 response, that could be because there's a problem with keepalives (yes of course they can work around it, but we want to avoid breaking existing configs). On the basis of your analysis, I'd be +1 for checking the Connection header, and setting AP_CONN_CLOSE iff it doesn't ask for keep-alive. The logic is provided by ap_set_keepalive, it is called right after basic_http_header_check in ap_http_header_filter. I believe the absence of the header in the last variant does regard RFC2616 (as 19.6.2 states). Indeedie. But a forced 1.0 response is a workaround for agents that fail to support RFC2616 correctly, so that's not really the point. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: AP_CONN_CLOSE on force-response-1.0
Jim Jagielski wrote: On Oct 9, 2007, at 12:40 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: I might be confused here, but if the response is forced 1.0, then there are no keepalives in which case we want to *force* keepalives off. Actually two different settings, no? 1.0 supported explicit keepalives. But the force disabling is the main intent of the implementation, iirc. ie: they didn't behave right with Connection: Keep-Alive isn't there a connection-close variable trigger that should be used to enforce that?
Re: Broken URI-unescaping in mod_proxy
On 10/8/07 1:44 PM, Roy T. Fielding [EMAIL PROTECTED] wrote: For the millionth time, if that is a problem then separate the proxy module from the gateway (reverse proxy) module. They do not belong together. +1. This would sway me more to go back to the stock modules. The reverse proxy could be much more aggressive with keep-alives, connection pools, etc. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 9, 2007, at 1:49 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: On Oct 9, 2007, at 12:40 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: I might be confused here, but if the response is forced 1.0, then there are no keepalives in which case we want to *force* keepalives off. Actually two different settings, no? 1.0 supported explicit keepalives. But the force disabling is the main intent of the implementation, iirc. ie: they didn't behave right with Connection: Keep-Alive isn't there a connection-close variable trigger that should be used to enforce that? All I'm saying is that, iirc, the intent of force-response-1.0 is to force a 1.0 response and disable keepalives... it was designed to work around buggy browsers that had problems with 1.1 features, including wonky 1.0-type keepalives. If someone wants to create force-response-1.0-with-keepalives that does what force-response-1.0 does but allows for the potential of keepalives, then I'm fine with that. But changing how force-response-1.0 behaves is *sure* to cause problems for those who depend on the current behavior.
Re: AP_CONN_CLOSE on force-response-1.0
On 10/9/07, Jim Jagielski [EMAIL PROTECTED] wrote: All I'm saying is that, iirc, the intent of force-response-1.0 is to force a 1.0 response and disable keepalives... it was designed to work around buggy browsers that had problems with 1.1 features, including wonky 1.0-type keepalives. No, you are thinking of downgrade-1.0 or nokeepalive. force-response-1.0, according to the docs, is only supposed to change the response-line, and nothing else. It was specifically designed for stupid clients (AOL) that couldn't handle a response with HTTP/1.1 in the response line, even if only HTTP/1.0 features were used. See: http://httpd.apache.org/docs/2.2/env.html#special Joshua.
Re: svn commit: r583247 - /httpd/mod_ftp/trunk/modules/ftp/ftp_util.c
[EMAIL PROTECTED] wrote: Permit third numerical form of IPv6 addresses, e.g. ::n.n.n.n although this form will almost certainly fail proxyport equality tests. With this patch, we now implement RFC2428, which was my only hesitation to at least throwing out an alpha release for users to experiment with. However it does need a bit of love in the proxy IP comparisons to tolerate the more bizzare aspects of IPV6_MAPPED_IPV4 addresses, and perhaps decode the ::n.n.n.n form into a pure ipv6 form for proxy IP comparison. There are some remaining build questions, such as how to make it simpler to build/install from the /top level/ of the package but still using apxs for simplicity (instead of descending into modules/ftp and invoking make -f Makefile.apxs there); as well we need to ensure it plugs in very smoothly if they want to simply unpack on top of httpd, without reinvoking buildconf, of course. But does anyone have other concerns before we prepare to release a first alpha version here of the module? Bill
Re: AP_CONN_CLOSE on force-response-1.0
On Oct 9, 2007, at 2:19 PM, Joshua Slive wrote: On 10/9/07, Jim Jagielski [EMAIL PROTECTED] wrote: All I'm saying is that, iirc, the intent of force-response-1.0 is to force a 1.0 response and disable keepalives... it was designed to work around buggy browsers that had problems with 1.1 features, including wonky 1.0-type keepalives. No, you are thinking of downgrade-1.0 or nokeepalive. force-response-1.0, according to the docs, is only supposed to change the response-line, and nothing else. It was specifically designed for stupid clients (AOL) that couldn't handle a response with HTTP/1.1 in the response line, even if only HTTP/1.0 features were used. See: http://httpd.apache.org/docs/2.2/env.html#special Hasn't force-response-1.0 been disabling keepalives for *years*?? If I recall, again it's been awhile, the keepalive thing was a major part of the problem... I can't see changing the behavior now, after all these years. If we want to create a variant that maintains the feasibility of keepalives, then a big +1 for that, but it should be a new envvar, not changing the userland experience of an existing one... Just my 2c :)
Re: Problems on Suse
Hi Nick, I guess you're right, beats me why the distribution rpm was compiled with AP_DEBUG. Thank you very much, Deodoro Filho Nick Kew wrote: On Tue, 09 Oct 2007 14:54:27 -0300 Deodoro Filho [EMAIL PROTECTED] wrote: Can anyone help me ? Looks like the SuSE is compiled with debug, and is unhappy about you passing 0 for readbytes.
Re: AP_CONN_CLOSE on force-response-1.0
http://svn.apache.org/viewvc?view=revrevision=78967 That's a 1997 date, btw :)
AddOutputFilterByType vs. proxy in 2.0.x
Does anyone recall if there was any fallout from the change to allow ap_set_output_filter_by_type() to operate on proxy requests? http://issues.apache.org/bugzilla/show_bug.cgi?id=31226 http://svn.apache.org/viewcvs.cgi/httpd/httpd/branches/2.2.x/server/core.c?rev=327793r1=307031r2=327793 I'd like to backport to 2.0.x but it seems like there was a little bit of caution in the 2.2.x/trunk commits. -- Eric Covener [EMAIL PROTECTED]
Re: AddOutputFilterByType vs. proxy in 2.0.x
Eric Covener wrote: I'd like to backport to 2.0.x but it seems like there was a little bit of caution in the 2.2.x/trunk commits. Propose it in STATUS and let's see where that goes.
Re: Broken URI-unescaping in mod_proxy
Akins, Brian wrote: For the millionth time, if that is a problem then separate the proxy module from the gateway (reverse proxy) module. They do not belong together. +1. This would sway me more to go back to the stock modules. The reverse proxy could be much more aggressive with keep-alives, connection pools, etc. As I recall there is very little difference between the code for forward proxy and the code for reverse proxy, the key differences being to send a Proxy-Auth instead of Auth where appropriate, and other minor things. Separating the module into two will just mean two modules with virtually identical code: a breeding ground for all sorts of problems. Regards, Graham --
Re: Broken URI-unescaping in mod_proxy
On Wed, 10 Oct 2007 00:17:18 +0200 Graham Leggett [EMAIL PROTECTED] wrote: As I recall there is very little difference between the code for forward proxy and the code for reverse proxy, the key differences being to send a Proxy-Auth instead of Auth where appropriate, and other minor things. There's quite a lot of difference in the path manipulation, though both have similar bugs. Separating the module into two will just mean two modules with virtually identical code: a breeding ground for all sorts of problems. Not necessarily. A reworking can factor out more of the common code into proxy_util, leaving mod_proxy and mod_gateway as fairly slim modules. But pending a round tuit, the question remains academic. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: AP_CONN_CLOSE on force-response-1.0
On Tuesday 09 October 2007 22:12, Jim Jagielski wrote:
All I'm saying is that, iirc, the intent of force-response-1.0 is
to force a 1.0 response and disable keepalives... it was designed
to work around buggy browsers that had problems with 1.1 features,
including wonky 1.0-type keepalives.
Actually, there is no problem to figure out from where the line had came
first:
httpd-1.3.x/src/main$ svn diff -r 78966:78967
Index: http_protocol.c
===
--- http_protocol.c (revision 78966)
+++ http_protocol.c (revision 78967)
@@ -1090,9 +1090,16 @@
if (!r-status_line)
r-status_line = status_lines[index_of_response(r-status)];
-if (r-proto_num == 1000
-table_get(r-subprocess_env,force-response-1.0))
+/* mod_proxy is only HTTP/1.0, so avoid sending HTTP/1.1 error
response; + * kluge around broken browsers when indicated by
force-response-1.0 + */
+if (r-proxyreq
+ || (r-proto_num == 1000
+table_get(r-subprocess_env,force-response-1.0))) {
+
protocol = HTTP/1.0;
+ r-connection-keepalive = -1;
+}
else
protocol = SERVER_PROTOCOL;
httpd-1.3.x/src/main$ svn log -r 78967 http_protocol.c
r78967 | fielding | 1997-08-15 21:59:52 +0400 (Fri, 15 Aug 1997) | 3 lines
Force proxy to always respond as HTTP/1.0, which it was failing to
do for errors and cached responses.
No word about buggy browsers in the comment. The r-proxyreq condition was
removed later, but keepalive assignment had left untouched.
On Thursday 15 March 2001 13:00, Graham Leggett wrote:
Hi all,
This patch stops the forced downgrade of the connection to HTTP/1.0 for
proxy requests.
Work is currently being done to ensure that mod_proxy is compliant with
HTTP/1.1 - the downgrade needs to go for this to work :)
Regards,
Graham
The patch was committed.
httpd-2.0/modules/http$ svn log -r 88528 http_protocol.c
r88528 | chuck | 2001-03-16 10:37:12 +0300 (Fri, 16 Mar 2001) | 4 lines
Stops the forced downgrade of the connection to HTTP/1.0 for proxy
requests. Submitted by: Graham Leggett
Reviewed by: Chuck Murcko
httpd-2.0/modules/http$ svn diff -r 88527:88528 http_protocol.c
Index: http_protocol.c
===
--- http_protocol.c (revision 88527)
+++ http_protocol.c (revision 88528)
@@ -770,12 +770,10 @@
if (!r-status_line)
r-status_line = status_lines[ap_index_of_response(r-status)];
- /* mod_proxy is only HTTP/1.0, so avoid sending HTTP/1.1 error
response; - * kluge around broken browsers when indicated by
force-response-1.0 + /* kluge around broken browsers when indicated by
force-response-1.0 */
- if (r-proxyreq
- || (r-proto_num == HTTP_VERSION(1,0)
- apr_table_get(r-subprocess_env, force-response-1.0))) {
+ if (r-proto_num == HTTP_VERSION(1,0)
+ apr_table_get(r-subprocess_env, force-response-1.0)) {
*protocol = HTTP/1.0;
r-connection-keepalive = -1;
