Re: Prefer Draft Feedback

On 9 December 2011 04:56, James Snell <jasnell@gmail.com> wrote:
> Basically, if you're
> using Prefer for content-negotiation, you're likely doing it wrong.

Great.

> if the
> response cannot be unambiguously determined to be a representation
> response [...] then the client must inspect the content to
> determine the nature of the response [...]

Cool.

Regarding wait and Date and the text added since -05:

You recommend that the client use Date so that the server knows the
absolute time that a response is required.  I don't see that working
particularly well in practice.  I also want to caution against over
engineering.

It's very hard to know what time the client truly made a request, even
with a Date header.  At least at the client end, you can make some
assumptions so that you can compensate for clock drift and
request/response transit times.  Without a closed loop, it's virtually
impossible to guarantee good timing.

Pragmatically, I think that the only reasonable way to implement this
header at the server is to take the time of request receipt, add the
wait time, and use that as the end date.  That could mean that a
response is ready for delivery milliseconds after that time limit has
expired, and will ultimately be received some time past the clients
reported deadline.

The client is in the best position to observe latencies that the
server cannot see, and they are then able to make allowances.  That
could mean offloading complexity to a client, which I would ordinarily
be leery of doing.  However, once again, I expect that it will be a
very simple process.  If I absolutely can't wait more than 20s, I
might set wait=18 or even wait=15 and leave it at that.  I can't see
anything more complicated being necessary in 99% of cases.  For
applications with tight latency requirements, and strict resource
constraints, I can imagine that a fairly sophisticated solution could
be constructed...but it's probably unnecessary most places.

--Martin

Received on Saturday, 10 December 2011 03:48:34 UTC