Invert Request API

[chadwhitacre]

The current design of the verbose Request API has higher-order objects (Mappings, etc.) as the base value such as request.line.uri.path, with raw bytes in a .raw attribute. This is confusing. Rather, all objects representing a fundamental part of an HTTP message should be a bytes subclass, with higher-order objects available as attributes.

[chadwhitacre]

We'll want to roughly specify the whole API before we dive in, but as a note I'm thinking that we'll move wildcards from path into path.parts (alongside the int indexes there). See #188 and IRC.

[pjz]

Are you looking to have this also fix #13 ?

[chadwhitacre]

call

[pjz]

(around 0:32:00 to 0:35:00 in the above call, ICYC)

[chadwhitacre]

!m @pjz

[chadwhitacre]

Closing in favor of #526.

[chadwhitacre]

I really do like that requests print as HTTP messages. I suppose HTTP/2 mucks with that, and of course WSGI is lossy so this isn't guaranteed the same as what's on the wire.

(Pdb) print request
GET /~whit537/settings/close HTTP/1.1
Accept-Language: en-US,en;q=0.8
Accept-Encoding: gzip, deflate, sdch
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Host: localhost:8537
Cookie: []
Referer: http://localhost:8537/~whit537/settings/
Upgrade-Insecure-Requests: 1


(Pdb)

[chadwhitacre]

@Changaco at #357 (comment):

If we have enough time we should try to take care of #222 before 1.0.

Do you have enough to go on to get started on this?

[Changaco]

Do you have enough to go on to get started on this?

It would be useful to clarify the problem(s) we're trying to fix, and whether we're okay with making lots of breaking changes or if we should try to maintain backward compatibility wherever possible.

[chadwhitacre]

The problem is the confusion of wondering what type request.line.uri.path is. The suggested solution is that the names representing parts of an HTTP message always be bytes, with higher-order representations of those parts in attributes on the parts.

request.line.uri.path is currently a Mapping.

The proposal here is that request.line.uri.path be bytes, with request.line.uri.path.parts as the Mapping.

[Changaco]

I meant: is this issue only about fixing a small confusion, or do we actually want to completely revisit both the Request and Response APIs as the issue's title suggests?

[Changaco]

Regarding the Response class, I think we should kill the raise Response(...) pattern. Instead of creating new response objects everywhere, we should only use the one in the state. That would allow us to give it access to the website and request objects, and thus provide a richer API.

[chadwhitacre]

we should only use the one in the state

So that is what return response(400, 'xxx') is about. ;-) That looks a lot like the WSGI API, with request, response instead of environ, start_response.

do we actually want to completely revisit both the Request and Response APIs as the issue's title suggests?

That sounds like a deep rabbit hole. I've narrowed the scope of this ticket. :)