Re: Prefer Draft Feedback

Alex, thanks for the feedback, comments below...

On Sat, Dec 3, 2011 at 9:25 AM, Alex Rousskov
<rousskov@measurement-factory.com> wrote:
> On 12/02/2011 04:01 PM, James Snell wrote:
>> All,
>>
>> I would like to take a quick moment to solicit feedback on the current
>> version of the HTTP Prefer Header specification:
>>
>> http://tools.ietf.org/html/draft-snell-http-prefer-04
>
>
>> 6. The "return-no-content" Preference
>>
>>
>>    The "return-no-content" preference indicates that the user-agent
>>    wishes the server to not include an entity in the response to a
>>    successful request. Typically, such responses would use the 204 No
>>    Content status, but other codes MAY be used as appropriate.
>>    Regardless of the status returned, when honoring the "return-no-
>>    content" preference, the server MUST NOT include an entity within the
>>    response.
>
>
> Please try to rephrase this preference to reduce the chances that some
> servers will start responding with something like HTTP 200 (OK) without
> body and without zero Content-Length header and expect the clients to
> correctly frame such a malformed response.
>
> The preference cannot change message framing rules so for most response
> status codes "no-content" and "no entity" has to be interpreted as "zero
> length body" rather than "no body".
>

Ok, yeah, will take another run at this then.

>
>> 7. The "wait" Preference
>>
>>
>>    The "wait" preference can be used to establish an upper bound on the
>>    length of time, in seconds, the user-agent is willing to wait for a
>>    response, after which the user-agent may choose to abandon the
>>    request.  In the case generating a response will take longer than the
>>    time specified, the server, or proxy, can choose to either return a
>>    202 Accepted response, cancel processing, or continue attempting to
>>    complete the request.
>>
>>      wait = "wait" "=" delta-seconds
>
> Since clients often do not send a Date header, the message recipients
> would not be able to know how long the client has been waiting for. Do
> you expect the wait time to be measured locally at each hop? If not, you
> may want to require clients to send a date header with this preference.
>

Excellent point, I really hadn't considered that previously. The
application where we've implemented this previous already had
reasonable synchronization between the client and server clocks so it
never came up. Will make sure to add that bit in.

>
>> 3. The "return-accepted" Preference
>>
>>
>>    The "return-accepted" preference indicates that the user-agent
>>    prefers the server to respond with a 202 Accepted status in the case
>>    where the length of time it takes to generate a response will exceed
>>    some arbitrary threshold established by the server.
>
> A "202 Accepted" response is a response. Consider replacing "generate a
> response" with something like "generate a regular response".
>
>
> You have specified Prefer as a request header. Have you considered
> removing that restriction so that servers may send certain preferences
> in HTTP 1xx control messages or even regular responses (when the
> preference exceeds the lifetime of a single HTTP transaction)?
>
>

Considered it yes, but wasn't really able to come up with a practical,
non-theoretical use case so I didn't pursue it. If such a case
emerges, or if it can be demonstrated that Prefer would work
reasonably with a response, I will gladly remove the restriction.

> Thank you,
>
> Alex.

Received on Monday, 5 December 2011 18:44:54 UTC