2

I found a couple related questions here

What I'm trying too do is to implement pull request handler fo my sync service that tells if there were any changes to any user's object in the database. If changes were made I respond with a list of object names and its IDs. If there is no changes I send a 304 Not Modified response.

To control frequency of these request I came with an idea to add a Retry-After header in all responses. The problem is that Apache cut all headers when 304 response being sent.

According to RFC2616

If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers.

But Retry-After is not an entity-header. Am I wrong or missing something?

Is there any workarounds? If this can't be solved (304 response with Retry-After header) what are the other choices in this situation? Is it seems reasonable to use 204 No Content instead of 304 Not modified?

Community
  • 1
  • 1
Vladimir Prudnikov
  • 6,974
  • 4
  • 48
  • 57

1 Answers1

2

It turns out that Apache filters 304 Not Modified responses against a hard-coded set of header names. For version 2.2.x they are:

Connection, Keep-Alive, ETag, Content-Location, Expires, Cache-Control, Vary, Warning, WWW-Authenticate, Proxy-Authenticate, Set-Cookie, Set-Cookie2

One workaround is to overload a header in that list. For example, you could abuse the Warning header:

header("Warning: X-Retry-After: 60"); //tested on Apache 2.2.3 / PHP5.1.6

Also see: Putting detailed REST error message in HTTP Warning header, good/bad idea?

And note: despite Apache's implementation, RFC2616 seems to suggest that Retry-After is reasonable on 304 responses:

... This field MAY also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing the redirected request. ...

Community
  • 1
  • 1
humbletim
  • 1,128
  • 11
  • 10