[Web-SIG] WSGI for HTTP/2.0 ?

[Robert Collins]

On 21 September 2014 16:43, Roberto De Ioris <roberto at unbit.it> wrote:
>
>>
>> I've proposed using github issues instead of documents; we can
>> synthesis the issues into prose in the draft docs and reference code
>> itself. I think this will be easier to manage than having a dozen
>> different comment-documents in the repo.
>>
>> -Rob
>>
>
> I completely agree and i have already opened two 'issues'. If we change
> idea on how to work on it feel free to delete them :)

Cool, thank you!

I've put my thoughts up in them, and pulled out what I think are
clearly sane requirements from them into a nascent requirements.rst
file.

I haven't closed the issues, since the actual spec covering those
requirements doesn't exist. And that leads to what is I think a fairly
key question.

Do we:
 - incorporate PEP-3333 by reference [e.g. by saying 'any HTTP/1.{0,1}
request will be processed as per PEP-3333']
or
 - do we want to alter how HTTP/1.{0,1} requests are presented (e.g.
tackling encoding of headers etc)

If the former, I think we have a new spec which will overlap a lot
with WSGI but we can avoid talking about the war; if its the latter, I
think we need a spec which is a copy-plus-adjust version of 3333.

If we represent headers etc differently for HTTP/2, folk with ordinary
needs will be affected - I can imagine them needing to have different
codepaths for HTTP/1.1 vs HTTP/2, which would hurt.

So I'd like to propose that we:
 - focus on great HTTP/2 semantics
 - have a full spec covering HTTP/1.{0,1}, HTTP/2 and websockets
 - and reference PEP-3333 only in the context of compatibility / shims
and the like

This isn't to say that I think we should make spurious changes to WSGI
- I don't think we should;  but I think we'll deliver a poor result if
we have two different models that folk have to know about for common
case 'I'm just answering a web request' scenarios.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud