InCommon metadata support

[Ian Young <>]

On 13 Jan 2017, at 01:00, Tom Poage <> wrote:

Two part question:

The MDQ beta server doesn't look to support conditional GET. Are there plans to do so? Does it make sense to do so?

You are correct to deduce that the current mdq-beta does not support conditional GET. It is a deployment of this implementation:

https://github.com/iay/mdq-server

It's a partial implementation of the specification. The corresponding enhancement request is here:

https://github.com/iay/mdq-server/issues/7

There are a couple of reasons why this hasn't yet reached the top of the pile, the strongest of which being that the current deployment regenerates the signed metadata every hour and this makes it unlikely that an eligible conditional GET will happen within that window.

A production service (whether based on mdq-beta or on different technology) would be much more likely to get value from conditional GET, and it would be more likely to be implemented at that point.

4.1.  Conditional Retrieval

  Upon a successful response the responder MUST return an ETag header
  and MAY return a Last-Modified header as well.  Requesters SHOULD use
  either or both, with the ETag being preferred, in any subsequent
  requests for the same resource.  In the event that a resource has not
  changed since the previous request, the requester will receive a 304
  (Not Modified) status code as a response.

I intend to review quite a bit of the text related to conditional GET and cacheing in light of the reformulation of HTTP/1.1 that happened (relatively) recently. In this case, it's probably more appropriate for the text to be:

    In the event that a resource has not

    changed since the previous requests, the responder SHOULD send a 304

    (Not Modified) status code as a response.

Hope that helps.

    -- Ian