- From: Adrien de Croy <adrien@qbik.com>
- Date: Thu, 10 Jun 2010 11:34:23 +1200
- To: "Thomson, Martin" <Martin.Thomson@andrew.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Greg Wilkins <gregw@webtide.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>
On 10/06/2010 11:18 a.m., Thomson, Martin wrote: > However I don't understand the issue where you discuss non-idempotent >> requests, and using a new connection. I don't know what this actually >> gives you. >> >> In the case where there is a proxy, and say the proxy starts sending >> the >> request on an idle connection to a server at the same time as the >> server >> closes the connection, then the proxy will report an error to the >> client, and the server never got the request, and the client can retry. >> > That's precisely the problem - they can't. If you send a non-idempotent request, it's not safe to retry the request. Without a response you have no idea what happened. You can't retry automatically. > I don't see what the difference is between a new proxy connection returning a 504 (e.g. the proxy can't connect to the server) vs proxy reporting 504 connection aborted on an old connection before the proxy could send the request to the server. So relying on that seems misguided to me. > Many HTTP implementations create a new connection for non-idempotent requests, which reduces the chances of losing the connection. That's inefficient. Hence: Connection-Timeout. > OK, I understand they may do that (albeit deludedly). Should we solve it by adding more headers which we may not be able to believe anyway, or fix the clients / proxies so that errors of that nature can be reported reliably and non-idempotent requests safely retried? > > >> What are you referring to when you mention a "null response"? Is this >> like a 204 response? >> > I've seen 200, 204, 304 - it matters little, though we should probably clarify that point :) > > >> I guess if intermediaries are between the client >> and server, the next request could come in on another connection. >> However if you used a 1xx response, the same connection could be used >> to >> send the final response when an event actually occurs. So I believe >> 1xx >> response has benefits for long polling. >> > To the extent that it ensures that the connection remains open, sure. You still need to know when the 1xx is required. > Sure, that could use the same heuristics at the server that a client would use. Cheers Adrien > --Martin > >
Received on Wednesday, 9 June 2010 23:35:04 UTC