view tests/test-batching.py.out @ 37049:55e901396005

hgweb: also set Content-Type header

Our HTTP/WSGI server may convert the Content-Type HTTP request
header to the CONTENT_TYPE WSGI environment key and not set
HTTP_CONTENT_TYPE. Other WSGI server implementations
do this, so I think the behavior is acceptable.

So assuming this HTTP request header could get "lost" by the WSGI
server, let's restore it on the request object like we do for
Content-Length.

FWIW, the WSGI server may also *invent* a Content-Type value. The
default behavior of Python's RFC 822 message class returns a default
media type if Content-Type isn't defined. This is kind of annoying.
But RFC 7231 section 3.1.1.5 does say the recipient may assume a media
type of application/octet-stream. Python's defaults are for
text/plain (given we're using an RFC 822 parser). But whatever.

Differential Revision: https://phab.mercurial-scm.org/D2849

== Local
Ready.
Un and Deux
Eins und Zwei
One and Two
Eins und Zwei
Uno und Due
proper end of results generator

== Remote
Ready.
REQ: foo?one=Vo&two=Efvy
  -> Vo!boe!Efvy
Un and Deux
REQ: bar?b=Fjot&a=[xfj
  -> Fjot!voe![xfj
Eins und Zwei
REQ: batch?cmds=foo:one=Pof,two=Uxp;bar:b=Fjot,a=[xfj;bar:b=Vop,a=Evf
  -> Pof!boe!Uxp;Fjot!voe![xfj;Vop!voe!Evf
One and Two
Eins und Zwei
Uno und Due
proper end of results generator
Attempted to batch a non-batchable call to 'greet'
Attempted to batch a non-batchable call to 'hello'