Mercurial > hg
comparison mercurial/wireprotoserver.py @ 36855:2cdf47e14c30
hgweb: refactor the request draining code
The previous code for draining was only invoked in a few places in
the wire protocol. Behavior wasn't consist. Furthermore, it was
difficult to reason about.
With us converting the input stream to a capped reader, it is now
safe to always drain the input stream when its size is known because
we can never overrun the input and read into the next HTTP request.
The only question is "should we?"
This commit changes the draining code so every request is examined.
Draining now kicks in for a few requests where it wouldn't before.
But I think the code is sufficiently restricted so the behavior is
safe. Possibly the most dangerous part of this code is the issuing
of Connection: close for POST and PUT requests that don't have a
Content-Length. I don't think there are any such uses in our WSGI
application, so this should be safe.
In the near future, I plan to significantly refactor the WSGI
response handling. I anticipate this code evolving a bit. So any
minor regressions around draining or connection closing behavior
might be fixed as a result of that work.
All tests pass with this change. That scares me a bit because it
means we are lacking low-level tests for the HTTP protocol.
Differential Revision: https://phab.mercurial-scm.org/D2769
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Sat, 10 Mar 2018 11:03:45 -0800 |
parents | d6cd1451212e |
children | da4e2f87167d |
comparison
equal
deleted
inserted
replaced
36854:290fc4c3d1e0 | 36855:2cdf47e14c30 |
---|---|
299 elif isinstance(rsp, wireprototypes.pushres): | 299 elif isinstance(rsp, wireprototypes.pushres): |
300 rsp = '%d\n%s' % (rsp.res, rsp.output) | 300 rsp = '%d\n%s' % (rsp.res, rsp.output) |
301 wsgireq.respond(HTTP_OK, HGTYPE, body=rsp) | 301 wsgireq.respond(HTTP_OK, HGTYPE, body=rsp) |
302 return [] | 302 return [] |
303 elif isinstance(rsp, wireprototypes.pusherr): | 303 elif isinstance(rsp, wireprototypes.pusherr): |
304 # This is the httplib workaround documented in _handlehttperror(). | |
305 wsgireq.drain() | |
306 | |
307 rsp = '0\n%s\n' % rsp.res | 304 rsp = '0\n%s\n' % rsp.res |
308 wsgireq.respond(HTTP_OK, HGTYPE, body=rsp) | 305 wsgireq.respond(HTTP_OK, HGTYPE, body=rsp) |
309 return [] | 306 return [] |
310 elif isinstance(rsp, wireprototypes.ooberror): | 307 elif isinstance(rsp, wireprototypes.ooberror): |
311 rsp = rsp.message | 308 rsp = rsp.message |
313 return [] | 310 return [] |
314 raise error.ProgrammingError('hgweb.protocol internal failure', rsp) | 311 raise error.ProgrammingError('hgweb.protocol internal failure', rsp) |
315 | 312 |
316 def _handlehttperror(e, wsgireq, req): | 313 def _handlehttperror(e, wsgireq, req): |
317 """Called when an ErrorResponse is raised during HTTP request processing.""" | 314 """Called when an ErrorResponse is raised during HTTP request processing.""" |
318 | |
319 # Clients using Python's httplib are stateful: the HTTP client | |
320 # won't process an HTTP response until all request data is | |
321 # sent to the server. The intent of this code is to ensure | |
322 # we always read HTTP request data from the client, thus | |
323 # ensuring httplib transitions to a state that allows it to read | |
324 # the HTTP response. In other words, it helps prevent deadlocks | |
325 # on clients using httplib. | |
326 | |
327 if (req.method == 'POST' and | |
328 # But not if Expect: 100-continue is being used. | |
329 (req.headers.get('Expect', '').lower() != '100-continue')): | |
330 wsgireq.drain() | |
331 else: | |
332 wsgireq.headers.append((r'Connection', r'Close')) | |
333 | 315 |
334 # TODO This response body assumes the failed command was | 316 # TODO This response body assumes the failed command was |
335 # "unbundle." That assumption is not always valid. | 317 # "unbundle." That assumption is not always valid. |
336 wsgireq.respond(e, HGTYPE, body='0\n%s\n' % pycompat.bytestr(e)) | 318 wsgireq.respond(e, HGTYPE, body='0\n%s\n' % pycompat.bytestr(e)) |
337 | 319 |