proxy for HTTP 1.0 clients

I think mod_proxy in Apache 1.3.24 (and I guess 1.3.23) has a problem
with HTTP 1.0 clients. I have looked at the source and it is hard coded
to use HTTP 1.1, regardless of what version the client is using. The
problem I'm running into is when I use mod_rewrite with the [P] flag to
pass a request into mod_proxy. If a client requests the URL using HTTP
1.0, mod_proxy returns a HTTP 1.1 response for the HTTP 1.0 request.
The real problem is that the data is chunked, and the client doesn't
expect that so it doesn't "unchunk" it. You can see what I'm talking
about if you use Netscape 4.x to go here: http://wwwtest.golfcpons.com/
.. In addition, I've manually sent a request and pasted the results at
the bottom of this e-mail for you to look at.

HTTP/1.1 clients work fine with this setup and everything was great
until the HTTP 1.1 support was added to mod_proxy.

Any suggestions, corrections, or hope of a fix on the horizon?

============================================================ ==========
GET / HTTP/1.0
Host: wwwtest.golfcpons.com
Connection: close

HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 23:46:54 GMT
Server: Apache/1.3.24 (Unix) mod_jk/1.1.0 mod_ssl/2.8.8 OpenSSL/0.9.6b
Cache-Control: no-cache
Content-Type: text/html
Pragma: no-cache
Set-Cookie: JSESSIONID=7u5cuovp71;Path=/
Transfer-Encoding: chunked
X-Cache: MISS from wwwtest.golfcpons.com
Connection: close

1ff8



........

Re: proxy for HTTP 1.0 clients

Okay, you're definitely going to want to look this over since I have no
experience writing Apache modules. It's a quickie. This patch for
src/modules/proxy/proxy_http.c seems to have fixed the problem. It
takes the version number from the original request and uses it in the
proxy request.

If you're using mod_ssl, apply the patch *after* configuring mod_ssl.
Otherwise everything gets messed up.

--- proxy_http.c Thu Mar 21 06:38:03 2002
+++ /tmp/proxy_http.c Tue Apr 9 23:57:30 2002
@@ -305,2 +305,5 @@
- ap_bvputs(f, r->method, " ", proxyhost ? url : urlptr, " HTTP/1.1"
CRLF,
- NULL);
+ ap_bvputs(f, r->method, " ", proxyhost ? url : urlptr,
+ ap_psprintf(p, " HTTP/%d.%d",
+ HTTP_VERSION_MAJOR(r->proto_num),
+ HTTP_VERSION_MINOR(r->proto_num)),
+ CRLF, NULL);

On Wed, 2002-04-10 at 00:18, Ben Gunter wrote:
I think mod_proxy in Apache 1.3.24 (and I guess 1.3.23) has a problem
with HTTP 1.0 clients. I have looked at the source and it is hard coded
to use HTTP 1.1, regardless of what version the client is using. The
problem I'm running into is when I use mod_rewrite with the [P] flag to
pass a request into mod_proxy. If a client requests the URL using HTTP
1.0, mod_proxy returns a HTTP 1.1 response for the HTTP 1.0 request.
The real problem is that the data is chunked, and the client doesn't
expect that so it doesn't "unchunk" it. You can see what I'm talking
about if you use Netscape 4.x to go here: http://wwwtest.golfcpons.com/
. In addition, I've manually sent a request and pasted the results at
the bottom of this e-mail for you to look at.

HTTP/1.1 clients work fine with this setup and everything was great
until the HTTP 1.1 support was added to mod_proxy.

Any suggestions, corrections, or hope of a fix on the horizon?

============================================================ ==========
GET / HTTP/1.0
Host: wwwtest.golfcpons.com
Connection: close

HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 23:46:54 GMT
Server: Apache/1.3.24 (Unix) mod_jk/1.1.0 mod_ssl/2.8.8 OpenSSL/0.9.6b
Cache-Control: no-cache
Content-Type: text/html
Pragma: no-cache
Set-Cookie: JSESSIONID=7u5cuovp71;Path=/
Transfer-Encoding: chunked
X-Cache: MISS from wwwtest.golfcpons.com
Connection: close

1ff8



.......

Re: proxy for HTTP 1.0 clients

This is a cryptographically signed message in MIME format.

--------------ms0EC3A71EEB2E9195C8291640
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben Gunter wrote:

> I think mod_proxy in Apache 1.3.24 (and I guess 1.3.23) has a problem
> with HTTP 1.0 clients.

This problem is fixed in v1.3.25-dev.

The 1.3.24 proxy did not know how to dechunk incoming responses from
HTTP/1.1 servers, which meant the chunked encoding was being sent as is
to the client. If the client was HTTP/1.1 it didn't complain, but
obviously HTTP/1.0 clients have a problem. Now the proxy dechunks
incoming chunked responses as required by RFC2616.

> I have looked at the source and it is hard coded
> to use HTTP 1.1, regardless of what version the client is using.

This is correct according to RFC2616.

Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
--------------ms0EC3A71EEB2E9195C8291640
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIHyAYJKoZIhvcNAQcCoIIHuTCCB7UCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCC
BcYwggKVMIIB/qADAgECAgMEyOwwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNV BAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G A1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf UGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA1MTEwMDE3NDZaFw0wMjA1 MTEwMDE3NDZa
MF0xEDAOBgNVBAQTB0xlZ2dldHQxDzANBgNVBCoTBkdyYWhhbTEXMBUGA1UE AxMOR3JhaGFt
IExlZ2dldHQxHzAdBgkqhkiG9w0BCQEWEG1pbmZyaW5Ac2hhcnAuZm0wgZ8w DQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBALX2zJvQ/9l+sCEpkfMNNwtnMcF8vmPM2sRpibT5 nR87bYWyLVCt
XXWXU+UyDOkiQJt6UahnmYZV7u40a1/osbNnjHjyNybejOuUFjHYy1gDwjsE lnxYbRRA2SZc
CmrZ4V0QFI0ZKuimGryZQj77UroiIV+Qq+v+PaxDEGwiqJqnAgMBAAGjLTAr MBsGA1UdEQQU
MBKBEG1pbmZyaW5Ac2hhcnAuZm0wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQCO
l5bH8JXuFM+EZi01jfezzKML5iPBHx4BDj/4gl2lXw1t0v6o+9442F6TpnOV Ak3LL1KTupvc
HfM+Bn71iWuD8ASCoSsmVpeoCbOv3lPGltrDgywcmM8phZyK1hHLvvJgfd4I MZbuH/rm0ZWp
WjRORFfik8yuO9DgahgjgAhkujCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcN AQEEBQAwgdEx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93
bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24g
U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMDA4
MzAwMDAwMDBaFw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2Vz
dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0 ZTEdMBsGA1UE
CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZy ZWVtYWlsIFJT
QSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZj xwklRT7Sbngn
Z4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN +kvx1t1hpfmF
zVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/ s5udSWYALQmJ
7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2 YXRlTGFiZWwx
LTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG 9w0BAQQFAAOB
gQBzG28mZYv/FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvh zeY42e1Q9Dps
NJKs5pKcbsEjAcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga 7TlbOX00/LaW
GCVNavSdxcORL6mWuAU8Uvzd6WIDSDGCAcowggHGAgEBMIGaMIGSMQswCQYD VQQGEwJaQTEV
MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzAN BgNVBAoTBlRo
YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMT H1BlcnNvbmFs
IEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwTI7DAJBgUrDgMCGgUAoIGGMBgG CSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDQxMDA2NDU0NFow IwYJKoZIhvcN
AQkEMRYEFKoLITJwT6ooOYYAj+nVFpQ0yCaVMCcGCSqGSIb3DQEJDzEaMBgw BwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAOAzzZ5Wkoq3hJBVRy RVIjR5/jSelR
KWY0TA5ns0nMKsJUIBSCgsfZEGKeD2Fu1zSbxuFoD57pq6YlNZGw5C0Bfmko iRmziCd9Rp4x
ulBV3YzPBR0Ab7kJAD5w9cLKhGjP9HDDaYBC3RCE8d63OC09vRcwh4vz72qo TqhrXjWWMw==
--------------ms0EC3A71EEB2E9195C8291640--