Merge lp:~vila/bzr/2.2-568421-http-error-length into lp:bzr/2.2
Status: | Merged |
---|---|
Approved by: | Vincent Ladeuil |
Approved revision: | no longer in the source branch. |
Merged at revision: | 5062 |
Proposed branch: | lp:~vila/bzr/2.2-568421-http-error-length |
Merge into: | lp:bzr/2.2 |
Diff against target: |
58 lines (+38/-0) 2 files modified
NEWS (+3/-0) bzrlib/tests/http_server.py (+35/-0) |
To merge this branch: | bzr merge lp:~vila/bzr/2.2-568421-http-error-length |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
John A Meinel | Needs Fixing | ||
Review via email: mp+30423@code.launchpad.net |
Commit message
Set a Content-Length header on errors for HTTP/1.1
Description of the change
Targeting 2.2 since this concerns maverick and using the right basis this time.
This fixes bug #568421 which was only occurring on gentoo when pycurl was used with gnutls
so far (which made it harder to reproduce, at least for me).
This is due to a long standing bug in the python BaseHTTPServer: some http/1.1 clients requires a length even if the connection is closed. pycurl/gnutls seems to be the only combination choking on this one (but pycurl is also pretty pedantic about connection closes).
It looks like maverick changed the ssl implementation used for pycurl (which made the bug easier to reproduce) so the diagnosis was easier.
There is no easy way to reuse the base send_error so I went for a simplified implementation less likely to fail in the future.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vincent Ladeuil wrote: unknown_ file fails for pycurl if curl was compiled against gnutls /bugs.launchpad .net/bugs/ 568421
> Vincent Ladeuil has proposed merging lp:~vila/bzr/2.2-568421-http-error-length into lp:bzr/2.2.
>
> Requested reviews:
> bzr-core (bzr-core)
> Related bugs:
> #568421 test_get_
> https:/
>
>
> Targeting 2.2 since this concerns maverick and using the right basis this time.
>
> This fixes bug #568421 which was only occurring on gentoo when pycurl was used with gnutls
> so far (which made it harder to reproduce, at least for me).
>
> This is due to a long standing bug in the python BaseHTTPServer: some http/1.1 clients requires a length even if the connection is closed. pycurl/gnutls seems to be the only combination choking on this one (but pycurl is also pretty pedantic about connection closes).
>
> It looks like maverick changed the ssl implementation used for pycurl (which made the bug easier to reproduce) so the diagnosis was easier.
>
> There is no easy way to reuse the base send_error so I went for a simplified implementation less likely to fail in the future.
>
Consider my comments on the bzr.dev proposal to apply here.
review: needsfixing
(fine to land on 2.2, as long as we don't send content-length
inappropriately, and the class attributes are put somewhere discoverable.)
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkx FwBYACgkQJdeBCY SNAAP+ZwCgr3Mto aWbABdeHHpKqJNi 2gbi ozBWnjxMjrO3yLX jd
8mYAoMOrHt209Zo
=0X6m
-----END PGP SIGNATURE-----