On Windows, output streams are buffered when redirected to a file, and
TerminateProcess() apparently doesn't trigger a flush. This left
test-http-proxy.t missing part of the last line when it cat'd proxy.log[1].
Flushing stderr is all that is needed (on py27 anyway). I originally flushed
stdout too, but that added additional output to the log:
$ cat proxy.log
+ Accept: $LOCALIP (localhost)\r (esc)
+ Serving HTTP on 0.0.0.0 port 20810 ...\r (esc)
+ connect to localhost:$HGPORT\r (esc)
* - - [*] "GET http://localhost:$HGPORT/?cmd=capabilities HTTP/1.1" - - (glob)
+ bye\r (esc)
+ connect to localhost:$HGPORT\r (esc)
* - - [*] "GET http://localhost:$HGPORT/?cmd=branchmap HTTP/1.1" - - x-hgproto-1:0.1 0.2 comp=*zlib,none,bzip2 (glob)
+ bye\r (esc)
+ connect to localhost:$HGPORT\r (esc)
* - - [*] "GET http://localhost:$HGPORT/?cmd=stream_out HTTP/1.1" - - x-hgproto-1:0.1 0.2 comp=*zlib,none,bzip2 (glob)
+ bye\r (esc)
+ connect to localhost:$HGPORT\r (esc)
...
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096987.html
The BaseHTTPServer, SimpleHTTPServer and CGIHTTPServer has been merged into
http.server in python 3. All of them has been merged as util.httpserver to use
in both python 2 and 3. This patch adds a regex to check-code to warn against
the use of BaseHTTPServer. Moreover this patch also includes updates to lower
part of test-check-py3-compat.t which used to remain unchanged.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
test-http-proxy.t sometimes failed with:
File ".../tests/tinyproxy.py", line 110, in _read_write
data = i.recv(8192)
error: (104, 'Connection reset by peer')
This might have started showing up with 9eb533d10f1a ... but it has apparently
also been seen before. I don't see anything in 9eb533d10f1a that can explain
it. It seems to be a race in test, in the tinyproxy helper:
Tinyproxy found an incoming socket using select(). It would break the loop if
an error had been detected on the socket, but there was no error and it tried
to recv() from the socket. That failed - apparently because it had been reset
after select().
Errors in the recv() will now be caught and will break the loop like errors
detected by select() would.
(send() could also fail in a similar way ... but using the same solution there
and losing data we have read doesn't feel right.)
Send the command arguments in the HTTP headers. The command is still part
of the URL. If the server does not have the 'httpheader' capability, the
client will send the command arguments in the URL as it did previously.
Web servers typically allow more data to be placed within the headers than
in the URL, so this approach will:
- Avoid HTTP errors due to using a URL that is too large.
- Allow Mercurial to implement a more efficient wire protocol.
An alternate approach is to send the arguments as part of the request body.
This approach has been rejected because it requires the use of POST
requests, so it would break any existing configuration that relies on the
request type for authentication or caching.
Extensibility:
- The header size is provided by the server, which makes it possible to
introduce an hgrc setting for it.
- The client ignores the capability value after the first comma, which
allows more information to be included in the future.
problems fixed:
- https scheme handled properly for real and proxy urls.
- url of form "http://user:password@host:port/path" now ok.
- no-proxy check uses proper host names.
