On 15 October 2014 11:58, Antoine Pitrou <solip...@pitrou.net> wrote:
> On Wed, 15 Oct 2014 11:28:42 +1300
> Robert Collins
> <robe...@robertcollins.net> wrote:
>> On 15 October 2014 11:10, Antoine Pitrou <solip...@pitrou.net> wrote:
>>
>> > Each time a connection is accepted, protocol_factory is called without
>> > arguments(**) to create a Protocol, a bidirectional stream Transport is
>> > created to represent the network side of the connection, and the two
>> > are tied together by calling protocol.connection_made(transport)."""
>>
>> So where would headers etc be supplied to the protocol for reads (and
>> for outputs)? Since the transport isn't the raw socket, its the bodies
>> only.
>
> For reads, it could be provided on e.g.
> transport.get_extra_info('headers'). Or if you want a flat mapping API,
> transport.get_extra_info('http_content_type'), etc.
>
> As for out-bound headers, it's a good question. But I think it's ok for
> the transport to have HTTP-specific methods, so
> transport.write_header(name, value) could be ok too.Ok so on balance I suspect that this is different enough to the needs for a blocking API - even with generators in use - that we're better off keeping them separate. But, for all the variables, headers etc, we can write a single definition of the semantics at play - e.g. see the REMOTE_ADDR one. Would that make sense as separate specs, the way RFC2616 has split into separate RFCs in in the 723x update ? Or one big spec with sections, and when a pep-3156 based protocol/api is put together just add a section? -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
