RE : RE : mod_proxy and HTTP/1.1 request

I tried lots of combinations (with or without proxy, in HTTP 1.1 or
1.0).
The communication beetween client and proxy is HTTP/1.1 (with
Proxy-Connection: Keep-Alive).
The communication beetween proxy and web server is HTTP/1.0 (with
Connection: Close).
It seems to be in line with RFC2616.
It is just a shame that your original patch worked on both side in
HTTP/1.1 and some code have got lost somewhere. Maybe it could cause
problems under certain cases ?

Regards,
Gael

> -----Message d'origine-----
> De : minfrin [mailto:minfrin] De la part de Graham Leggett
> Envoy=E9 : vendredi 8 mars 2002 17:49
> =C0 : modproxy-dev@apache.org
> Objet : Re: RE : mod_proxy and HTTP/1.1 request
>=20
>=20
> Gael Seroul wrote:
>=20
> > I don't think the problem is just a version string error. =20
> The traffic=20
> > I saw beetween apache proxy and web server was in HTTP/1.0 (The=20
> > header was containing the Content-Length, no chunk appeared...) The=20
> > communication beetween apache proxy and web server is really in=20
> > HTTP/1.0.
>=20
> Chunking is optional in RFC2616 - if the proxy receives=20
> content with a content-length, it won't chunk the data.
>=20
> If you could send a specific instance of where proxy violates=20
> RFC2616 I would appreciate it, because then I can fix it. To=20
> date the only reports so far are "it looks like HTTP/1.0",=20
> which is far too vague to be useful.
>=20
> Regards,
> Graham
> --=20
> -----------------------------------------
> minfrin@sharp.fm "There's a moon
> over Bourbon Street
> tonight..."
>=20

Re: RE : RE : mod_proxy and HTTP/1.1 request

This is a cryptographically signed message in MIME format.

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

Gael Seroul wrote:

> I tried lots of combinations (with or without proxy, in HTTP 1.1 or
> 1.0).
> The communication beetween client and proxy is HTTP/1.1 (with
> Proxy-Connection: Keep-Alive).
> The communication beetween proxy and web server is HTTP/1.0 (with
> Connection: Close).
> It seems to be in line with RFC2616.

Connection: close is HTTP/1.1 protocol, not HTTP/1.0. Keepalives are not
supported in the v1.3 patch (they are in the 2.0 proxy) and are
negotiated "no" in the standard 1.1 way.

> It is just a shame that your original patch worked on both side in
> HTTP/1.1 and some code have got lost somewhere. Maybe it could cause
> problems under certain cases ?

What code were you testing? The current head of CVS (what will become
v1.3.24) has all the fixes in it, including the HTTP/1.1 to the backend.
The v1.3.23 code has got a whole bunch of bugs in it.

I am going to have to check this thoroughly - I have absolutely no idea
how it got changed back, as all traces of HTTP/1.0 behaviour was removed
when I wrote the patch. I'm a bit swamped with work right now, so I
cannot look at it in the next few days, but hopefully I will get to it
by next week.

Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
--------------ms4427B200EF1BF9990ED32F82
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
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDMxMzExNTUxNlow IwYJKoZIhvcN
AQkEMRYEFOzz86kU5XIV9BVCanBeXG0Y/KoQMCcGCSqGSIb3DQEJDzEaMBgw BwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAXeMXB3qTHKINuGuNX AJMYX0NIJMCo
L1DHihb1beeDVKtTSsxnLRv6PzapowVEqZ+Yq8PzFQzBTKMLcCYaNb83QNry L2krJBUo2aif
K7GO3iq+2cCv2DPAFW9gvSmwXSD7W4CBIGMguZIME5THew+L+x5nFL/deDzg uQtH9D6liw==
--------------ms4427B200EF1BF9990ED32F82--

Re: RE : RE : mod_proxy and HTTP/1.1 request

On Wednesday, March 13, 2002, at 06:55 AM, Graham Leggett wrote:

> Gael Seroul wrote:
>
>> I tried lots of combinations (with or without proxy, in HTTP 1.1 or
>> 1.0).
>> The communication beetween client and proxy is HTTP/1.1 (with
>> Proxy-Connection: Keep-Alive).
>> The communication beetween proxy and web server is HTTP/1.0 (with
>> Connection: Close).
>> It seems to be in line with RFC2616.
>
> Connection: close is HTTP/1.1 protocol, not HTTP/1.0. Keepalives are not
> supported in the v1.3 patch (they are in the 2.0 proxy) and are
> negotiated "no" in the standard 1.1 way.
>
>> It is just a shame that your original patch worked on both side in
>> HTTP/1.1 and some code have got lost somewhere. Maybe it could cause
>> problems under certain cases ?
>
> What code were you testing? The current head of CVS (what will become
> v1.3.24) has all the fixes in it, including the HTTP/1.1 to the backend.
> The v1.3.23 code has got a whole bunch of bugs in it.
>
> I am going to have to check this thoroughly - I have absolutely no idea
> how it got changed back, as all traces of HTTP/1.0 behaviour was removed
> when I wrote the patch. I'm a bit swamped with work right now, so I
> cannot look at it in the next few days, but hopefully I will get to it
> by next week.
>

OK, the one line you changed recently was untouched in the patch to
1.3.19, so it happened sometime before that.

Ah, no, it looks like this might have been untouched since day 1,
looking at your patch to 1.3.12 from April 7 2000. Was there a revised
version of this patch?

Chuck