Open Stack

On 06/19/2015 04:03 PM, Ian Cordasco wrote:
> 
> 
> On 6/19/15, 14:39, "Ian Cordasco" <ian.cordasco at RACKSPACE.COM> wrote:
> 
>>
>>
>> On 6/19/15, 14:26, "Kevin L. Mitchell" <kevin.mitchell at rackspace.com>
>> wrote:
>>
>>> On Fri, 2015-06-19 at 10:07 +0100, Chris Dent wrote:
>>>> * Are there additional relevant pros and cons for the two proposals?
>>>> * Are there additional proposals which can address the shortcomings
>>>>    in either?
>>>
>>> On the latter question, would using the If-Modified-Since header[1] make
>>> any sense as a possible solution?  That at least would be a standard
>>> HTTP convention for this sort of thing, and tends to match up with the
>>> semantics of a changes-since query parameter.
>>
>> First, please use the updated RFC references
>> (https://tools.ietf.org/html/rfc7232#section-3.3)
>>
>> If-Modified-Since does not. That's meant for entire resources. In other
>> words, let's say you're listing images in Glance and you do
>>
>>    GET /v2/images
>>
>> And your response has
>>
>>    HTTP/1.1 200 OK
>>    Last-Modified: some_last_modified_value
>>
>> In the headers, when you do
>>
>>    GET /v2/images
>>    If-Modified-Since: some_last_modified_value
>>
>> Then you should either get a:
>>
>>    HTTP/1.1 204 No Content
>>
>> Or
>>
>>    HTTP/1.1 200 OK
>>    Last-Modified: new_last_modified_value
>>
>>    (all of the images you saw before)
>>
>> In other words, If-Modified-Since is meant purely for the state of the
>> resource. It's main purpose is when used in conjunction with caching.
>>
>> That said, changes-since is more of a "delta". If you need an analogy,
>> think of it as an equivalent to
>>
>>    $ git log 2015.1.0..stable/kilo
>>
>> It's just the deltas after a certain timestamp.
> 
> Also, for what it's worth, I used to think If-Modified-Since was what you
> thought it was, but I found out how woefully wrong I was. It's not exactly
> intuitive, but you can toy with it via the GitHub API. Their /users and
> /repos resources will give you ETag and Last-Modified information. If you
> wait a little long enough for it to change and use either of those values
> to make a request, you'll get all of it again, from the beginning.

Right, it's the difference between the transport protocol semantics, and
the application. Standard HTTP headers are about the transport protocol
of HTTP, and do not care about your application. Here we're asking
something about the application.

	-Sean

-- 
Sean Dague
http://dague.net