Re: Prefer Draft Feedback

On Mon, Dec 5, 2011 at 12:12 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> [snip]
>>> 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.
>
>
> Well, a status message could have a content-location as well. Think a
> monitor resource after 202.
>
> I think the current language restricts servers from doing what's allowed
> today.
>
> Wouldn't (have Content-Location) AND (Content-Location == effective Request
> URI) work?
>

Unfortunately, no.. consider the Atom Publishing Protocol for
example.. when I POST a new item to the collection URI, the response
can include a representation of the created resource. The
Content-Location header would point to the location of the created
entry, while the effective request URI would be for the collection.

>> ...
>>
>>> 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
>> it.
>
>
> There was talk about this in the context of making long polling work better.
>

Ok... well like I said, I don't have a problem pulling this if it does
overlap. For now, however, until it's clear that something else
adequately covers this requirement, I'll keep it in.

>
>>> [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?
>
>
> The comparison rule.
>

Ok, I'm confused then. We've established that preference names are
case-insensitive and values are case-sensitive, so I'm not sure why
you're objecting to this one.

>> ...
>
>
> Best regards, Julian

Received on Monday, 5 December 2011 20:20:37 UTC