mnot / nbhttp Goto Github PK

opensource.mirroring.de sends a body on a 304; this causes a dump because nbhttp tries to parse this as a HTTP response.

The trivial fix is to remember if there's an outstanding message, and if not, to ignore the input (probably closing the conn, because it's borked).

However, once pipelining is supported this won't be a complete solution, because there may be outstanding responses and a body where it shouldn't be.

Also need to evaluate the server-side analogy.

Hi,

When I run "python spdy_client.py http://...... "

I

nbhttp uses recursion for many of its parsing algorithms, but this may present security issues.

E.g., common.py, when parsing a chunked body, will recurse through handle_input if more than a chunk is received at a time.

A very large chunk will cause a recursion overflow here.

This an similar places should put sane limits in place, where possible.

Here is the trace:
Traceback (most recent call last):
File "spdy_client.py", line 346, in
test_client(sys.argv[1])
File "spdy_client.py", line 339, in test_client
req_body_write, req_done = c.req_start("GET", request_uri, [], printer, dumm
y)
File "spdy_client.py", line 136, in req_start
return conn.req_start(method, uri, req_hdrs, res_start_cb, req_body_pause)
File "spdy_client.py", line 159, in req_start
self._output(self._ser_syn_frame(CTL_SYN_STREAM, FLAG_NONE, stream_id, req_h
drs))
File "C:\nbhttp\src\spdy_common.py", line 230, in _ser_syn_frame
data = struct.pack("!IIH%ds" % len(hdrs),
TypeError: object of type 'NoneType' has no len()

Should be easy.

e.g., idle connection timeouts, header size limits, url size limits, read timeouts.

The data flows are pretty convoluted; at a minimum, they need to be well-documented.

E/C support needs to be verified.

for multiple cores under python 2.6

Current implementation blocks on DNS lookups. I either need to implement DNS (push_udp?), use a separate process, or just punt for the time being.

http://code.google.com/p/pyev/

Can the nbhttp libaries (push_ctp, client & server/spdy_client, spdy_sever, etc) be used to implement a multi-threaded proxy server? Any comment or suggestion how to approach this? Thanks.

In one way, this is quite simple to support, but doing it in a generic fashion that makes sense in different use cases (server, proxy, reverse proxy, client) is a different matter.

Right now handle_input recurses a lot, often leading to unnecessary header checks, etc. First step is probably to instrument it and see where this hurts.