Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 16:27:01 -0800] rev 36874
tests: additional test coverage of archive web command
This command is special in a few ways. First, it is the only command
using the write() function from WSGI's start_response() function.
Second, it is setting a custom content-disposition header.
We change the test so it prints out full details of the HTTP
response. We also save the response body to a file so we can
verify its size and hash. The hash check will help ensure that
archive generation is deterministic.
Differential Revision: https://phab.mercurial-scm.org/D2790
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 15:46:29 -0800] rev 36873
hgweb: port static file handling to new response API
hgwebdir_mod hasn't received as much porting effort. So we had to
do some minor plumbing to get it to match hgweb_mod and to support
the new response object.
Differential Revision: https://phab.mercurial-scm.org/D2789
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 15:37:29 -0800] rev 36872
hgweb: remove one-off routing for file?style=raw
Now that both functions are using the same API, we can unify how
the command is called and perform command-specific behavior in the
command itself instead of in the high-level router.
Differential Revision: https://phab.mercurial-scm.org/D2788
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 20:36:34 -0800] rev 36871
hgweb: port most @webcommand to use modern response type
This only focused on porting the return value.
raw file requests are wonky because they go through a separate code
path at the dispatch layer. Now that everyone is using the same
API, we could clean this up.
It's worth noting that wsgirequest.respond() allows sending the
Content-Disposition header, but the only user of that feature was
removed as part of this change (with the setting of the header
now being performed inline).
A few @webcommand are not as straightforward as the others and
they have not been ported yet.
Differential Revision: https://phab.mercurial-scm.org/D2787
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 17:02:57 -0800] rev 36870
hgweb: support using new response object for web commands
We have a "requestcontext" type for holding state for the current
request. Why we pass in the wsgirequest and templater instance
to @webcommand functions, I don't know.
I like the idea of standardizing on using "requestcontext" for passing
all state to @webcommand functions because that scales well without
API changes every time you want to pass a new piece of data. So,
we add our new request and response instances to "requestcontext" so
@webcommand functions can access them.
We also teach our command dispatcher to recognize a new calling
convention. Instead of returning content from the @webcommand
function, we return our response object. This signals that this
response object is to be used for sending output. The keyword
extension was wrapping various @webcommand and assuming the output
was iterable, so we had to teach it about the new calling convention.
To prove everything works, we convert the "filelog" @webcommand
to use the new convention.
The new calling convention is a bit wonky. I intend to improve this
once all commands are ported to use the new response object.
Differential Revision: https://phab.mercurial-scm.org/D2786
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 14:19:27 -0800] rev 36869
hgweb: inline caching() and port to modern mechanisms
We only had one consumer of this simple function. While it could be
a generic function, let's not over abstract the code.
As part of inlining, we port it off wsgirequest, fix some Python 3
issues, and set a response header on our new response object so it
is ready once we start using it to send responses.
Differential Revision: https://phab.mercurial-scm.org/D2785
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 14:06:58 -0800] rev 36868
hgweb: expose repo name on parsedrequest
I'm not a fan of doing this because I want to find a better solution to
the REPO_NAME hack. But this change gets us a few steps closer to
eliminating use of wsgirequest. We can worry about fixing REPO_NAME
once wsgirequest is gone.
Differential Revision: https://phab.mercurial-scm.org/D2784