On Sep 14, 2006, at 11:36 AM, James Y Knight wrote:
The client that's in there right now is a low-level http client.
The higher level web client (the connection manager, queuing,
pooling, etc.) is not completed. That is where the retry logic and
the determination of which requests can be pipelined and which
cannot would go.
Okay, cool. So is twisted.web.client (and its dependencies) not going
to be included in this deprecation, or is there going to be a
temporary regression in functionality? I have no strong opinion; an
HTTP/1.0 client wasn't that useful to me to begin with.
Please note that even *keepalive* can only be (reliably) used for
idempotent actions. For example, client sends request A, gets
response A, sends request B, but at the same time, server closes
the connection from a timeout condition.
Ugh, you're right. Looking over RFC 2616 section 8.1.4, they say the
same thing you do:
"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)."
It does seem like this problem could have been avoided by the server
(after gracefully closing) simply reading and discarding that request
- the client would get the FIN and no RST. There's no circumstance in
which a server handles a request and then cleanly closes the
connection without a response, so it would know the server did not
handle request B. It would have to retry, but it could do so safely
even for non-idempotent requests. I wonder why they didn't do
that...bandwidth?
This could be a practical problem for me. I'm stuck using a protocol
created by a wannabe standards body that has mandated (1) a non-
idempotent sequence and (2) the client never closing the connection.
(And no, this is not the first time they've contradicted an
underlying standard...)
--
Scott Lamb <http://www.slamb.org/>
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
