[Python-Dev] Better HTTP 1.1 support in http.server?

[Antoine Pitrou]

Hello,

I was wondering if it would be worth providing better HTTP 1.1 support
in http.server. The way I envision it, there would be a separate
HTTP11RequestHandler which would provide:

- a smart wfile with automatic chunk encoding (which relieves the API
user from manually handling chunk encoding or content length
calculation)
- keep-alive enabled by default
- HTTP 1.1 by default (BaseHTTPRequestHandler defaults to 1.0)

What do you think?

Regards

Antoine.


--
Software development and contracting: http://pro.pitrou.net


_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com

[Christian Heimes]

Am 24.09.2012 17:27, schrieb Antoine Pitrou:
>
> Hello,
>
> I was wondering if it would be worth providing better HTTP 1.1 support
> in http.server. The way I envision it, there would be a separate
> HTTP11RequestHandler which would provide:
>
> - a smart wfile with automatic chunk encoding (which relieves the API
> user from manually handling chunk encoding or content length
> calculation)
> - keep-alive enabled by default
> - HTTP 1.1 by default (BaseHTTPRequestHandler defaults to 1.0)
>
> What do you think?

+1 for 3.4

You proposed gave me another idea. What do you think about SPDY support
in the stdlib? It's the next step after HTTP 1.1.

[Dirkjan Ochtman]

On Mon, Sep 24, 2012 at 6:39 PM, Christian Heimes <chri...@python.org> wrote:
> You proposed gave me another idea. What do you think about SPDY support
> in the stdlib? It's the next step after HTTP 1.1.

I'd wait it out a bit. SPDY is currently iterating, and there's an
effort to define HTTP 2 that will likely supersede SPDY (and may
incorporate many of its ideas).

http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI

On the other hand, some WebSockets support might be useful.

Cheers,

Dirkjan

[Senthil Kumaran]

On Mon, Sep 24, 2012 at 9:39 AM, Christian Heimes <chri...@python.org> wrote:
>
> +1 for 3.4
>
> You proposed gave me another idea. What do you think about SPDY support
> in the stdlib? It's the next step after HTTP 1.1.

Yeah, it is a good idea. it should live along side with HTTP 1.1 as
another protocol layer.
Guido had given some suggestions to takle that, but I have been lazing
and lagging for while now in terms of contributions, but I am excited
about the idea.

--
Senthil

[Felipe Cruz]

+1 for 3.4

And I'll be available to help with HTTP(websockets and SPDY) related stuff!

2012/9/24 Senthil Kumaran <sen...@uthcode.com>

Unsubscribe: http://mail.python.org/mailman/options/python-dev/felipecruz%40loogica.net

[David Wilson]

On 24 September 2012 19:39, Christian Heimes <chri...@python.org> wrote:
> Am 24.09.2012 17:27, schrieb Antoine Pitrou:
>>
>> Hello,
>>
>> I was wondering if it would be worth providing better HTTP 1.1 support
>> in http.server. The way I envision it, there would be a separate
>> HTTP11RequestHandler which would provide:
>>
>> - a smart wfile with automatic chunk encoding (which relieves the API
>> user from manually handling chunk encoding or content length
>> calculation)
>> - keep-alive enabled by default
>> - HTTP 1.1 by default (BaseHTTPRequestHandler defaults to 1.0)
>>
>> What do you think?
>
> +1 for 3.4
>
> You proposed gave me another idea. What do you think about SPDY support
> in the stdlib? It's the next step after HTTP 1.1.

Given the rate SPDY is changing, complexity of implementation, and
that some prerequisites aren't in place (zlib module needs to support
specifying the dictionary), this probably isn't a good idea right
away. It's also easy to get a similar effect using a SPDY-capable
reverse proxy.

>
> _______________________________________________
> Python-Dev mailing list
> Pytho...@python.org
> http://mail.python.org/mailman/listinfo/python-dev

> Unsubscribe: http://mail.python.org/mailman/options/python-dev/dw%40botanicus.net