-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Zed,
> But, if you're reading through the spec you might be able to help me > out, since I'm writing a test suite for this very purpose (and then > exploits around it). If you can, help me find the answers to these: I don't know very many of the answers to your questions since I've never implemented the pipelining part of an HTTP server before. Here's what I could find for a few of your questions from RFC 2616. Hope this helps. > 4) Who closes? It's not clear if the client closes, the server > closes, > who's allowed to close, when, what situations. This is really unclear > but incredibly important in a TCP/IP protocol, and in the HTTP RFC > it's > hidden in little SHOULD and MAY statements in all sorts of irrelevant > sections. http://rfc.net/rfc2616.html#s8.1.4 When a client or server wishes to time-out it SHOULD issue a graceful close on the transport connection. Clients and servers SHOULD both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does not detect the other side's close promptly it could cause unnecessary resource drain on the network. A client, server, or proxy MAY close the transport connection at any time. For example, a client might have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request is in progress. This means that clients, servers, and proxies MUST be able to recover from asynchronous close events. Client software SHOULD reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request sequence is idempotent (see section 9.1.2). Non-idempotent methods or sequences MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding of the application MAY substitute for user confirmation. The automatic retry SHOULD NOT be repeated if the second sequence of requests fails. Servers SHOULD always respond to at least one request per connection, if at all possible. Servers SHOULD NOT close a connection in the middle of transmitting a response, unless a network or client failure is suspected. Not completely clear, but gives a hint anyway. Hmm, is this one of those "irrelevant sections" you were talking about? ;-) > 5) What are the official size limits of each element of HTTP? Can > someone send a 1M header element? Header lengths? Actually I didn't see a direct reference, but there a hint in a round-about sort of way here: http://rfc.net/rfc2616.html#s19.4.7 HTTP implementations which share code with MHTML [45] implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see section 3.7.2) and does not interpret the content or any MIME header lines that might be contained therein. The key phrase being "implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation" leads me to believe they do not define any limit on header lengths. Actually the HTTP spec doesn't limit anything as far as I can tell. > 7) What's the allowed time limit for a client to complete it's > request? http://rfc.net/rfc2616.html#s8.1.4 Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server. The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client or the server. > 8) Are pipelined requests all sent at once, and then all processed at > once? Or, are they sent/processed/sent/processed in keeping with HTTP > request/response semantics. http://rfc.net/rfc2616.html#s8.1.1 Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time. http://rfc.net/rfc2616.html#s8.1.2.2 A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). - -- Thanks, Dan __________________________________________________________________ Dan Kubb Autopilot Marketing Inc. Email: [EMAIL PROTECTED] Phone: 1 (604) 820-0212 Web: http://autopilotmarketing.com/ vCard: http://autopilotmarketing.com/~dan.kubb/vcard __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFE2A8x4DfZD7OEWk0RAsvNAJwKpNaOf8J0+iWYUUdt9JqTU2aXWwCcDK1J oaRSXVCheKOBqd/m3cys4HA= =Lt+j -----END PGP SIGNATURE----- _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
