On Thu, 17 Feb 2000, Fred L. Drake, Jr. wrote: > Greg Stein writes: > > Pipelining is very important... it is once of the big advances in HTTP/1.1 > > (well, the advance is really the "chunked" transfer encoding which > > *allows* pipelining to occur more often). > > You should be able to pipeline requests even if responses don't use > chunking; Not in all cases. You can pipeline only if the server sends a Content-Length: header or uses chunking. There are a few other conditions (look at the httplib.HTTPResponse constructor in my httplib), but the Content-Length/chunking is the major point. > if I parse the first HTML page while still receiving, I > should be able to request non-cached images or other dependencies > before the first HTML is completely received. This allows the server > to locate the resources while still waiting for me finish pulling the > first response off the network. It improves the possibility of > scheduling resource location at the server (possibly important if > there's a dynamic backend) as well as avoiding establishing new TCP > connections. This would be nice, but my httplib currently enforces consumption before a new request. I do not recall the specific reasons why, but I imagine it would be possible to change it. [ today: you could certainly use a second connection object to improve client response, with the corresponding impact on the server ] > (Yes, some of this can be done with keep-alive stuff, but I don't > know that httplib supports that at all.) My httplib deals with the keep-alive header, when applicable (you are supposed to use Connection: in HTTP/1.1; it only looks at keep-alive if you aren't using 1.1). Cheers, -g -- Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4