On 6/19/15, 14:39, "Ian Cordasco" <ian.corda...@rackspace.com> wrote:

>
>
>On 6/19/15, 14:26, "Kevin L. Mitchell" <kevin.mitch...@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.

>Cheers,
>Ian

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to