W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: Prefer Draft Feedback

From: James Snell <jasnell@gmail.com>
Date: Mon, 5 Dec 2011 11:55:46 -0800
Message-ID: <CABP7RbdVLcgU_M3S0hQwTtysa3s9zDefeRwUy4LsTLA=W3YnFA@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Julian, again, thank you for feedback.. a few clarifying questions
below however...

On Sun, Dec 4, 2011 at 11:06 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> [snip]
>     return-content = "return-content"
> Maybe this should be called "return-representation".

I'm thinking "return-content" is going to be a bit more consistent
with other bits... such as "Content-Location".. but I'm not adverse to
renaming it.

> 5.  The "return-status" Preference
>   The "return-status" preference indicates that the user-agent prefers
>   the server to include an entity describing the status of the request
>   in the response as opposed to returning a representation of the
>   current state of the resource.
>     return-status = "return-status"
>   When honoring the "return-status" preference, the server SHOULD NOT
>   include a Content-Location header in the response.
> Why not?

I've gone back and forth on this particular point... essentially tho,
there really isn't any clear means of identifying when a particular
response is a representation of the resource or a representation of
the request status... there's absolutely nothing in the response that
I can key off of to make that determination reliably... The idea,
then, is to use the presence or lack of a Content-Location header as
that key. If I send return-content and get back a response with a
Content-Location header, then I assume it's a representation of the
resource and can assume the preference was applied, if I receive back
a response without a Content-Location, then I assume it's a status
response and have to handle it accordingly. I'm definitely open to a
better suggestion.

> 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.
>     return-no-content = "return-no-content"
>   The "return-no-content" preference is intended to provide a means of
>   optimizing communication between the user-agent and server by
>   reducing the amount of data the server is required to return to the
>   user-agent following a modification request.  This can be
>   particularly useful, for instance, when communicating with limited-
>   bandwidth mobile devices or when the user-agent simply does not
>   require any further information about the result of a request beyond
>   knowing if it was successfully processed.
> "return-minimal"?

Yeah, return-minimal is better... also, I'm removing the requirement
that the response be empty. It's better to allow the server to define
what constitutes an appropriate minimal response.

> 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
> Potential overlap with other work?

I've considered that also but I'm not sure. I haven't really seen much
that specifically deals with wait times, especially in an optional
arrangement such as this. I think for now, I'll leave this in and if
it becomes clear that there's overlap in other areas, I can revisit

> [snip]
> 11.  Registered Preferences
>   Well-defined preferences can be registered for convenience and/or to
>   promote reuse by other applications.  This specification establishes
>   an IANA registry of such relation types see Section Section 12.1.
>   Registered preference names MUST conform to the token rule, and MUST
>   be compared character-by-character in a case-insensitive fashion.
> No, this is inconsistent with the use in similar header fields (like
> Cache-Control)

Not sure what exactly you're objecting to here. Is it the registry or
the comparison rule?

> 13.  Security Considerations
>   Specific preferences requested by a client can introduce security
>   considerations and concerns beyond those discussed in [RFC2616].
> Be consistent in referencing HTTPbis *or* RFC2616.
> Editorial:
> Throughout: s/header/header field/
Received on Monday, 5 December 2011 19:57:40 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC