Originally Posted by
ftnoob
I might be behind the curve on this one, but I didn't see any clearly erroneous caching instructions sent from the server.
The caching instruction is implied by the 301 response code. HTTP response codes are defined to have certain behavior in
RFC 2616. The definition of response code 301 (Moved Permanently) begins with this text:
10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
In effect, this RFC tells browser-makers that when they get a HTTP 301 response, they needn't ask the server anymore for the original location, since the data will never be there, and more importantly (and perhaps dangerously), the data will ALWAYS be at the new location specified. I would argue that things are rarely permanent on the internet, but fortunately, it seems that modern browser manufacturers have taken "permanent" to mean "until the cache is emptied."
Originally Posted by
ftnoob
Can you double check this and confirm this specific change is needed?
I'm not sure if you're asking me or
IB-Dick, but there are several specific changes that are possible here. I suspect the easiest one is to adjust the magic new-post PHP to write some explicit no-cache headers, which is why that's the one I recommended. The ideal solution would be to move away from 301 altogether, as a permanent redirect is never intended here. So rather than giving some instructions and then immediately nullifying them, just start out with the proper instructions. Either HTTP 302 or HTTP 307 seems to be the proper response for this case:
10.3.8 307 Temporary Redirect
The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
This response code indicates that browsers should re-request the magic new-post page every time the user asks for it to ensure that the latest post is received.
Originally Posted by
ftnoob
I have seen both 302 and 307 mentioned, but this is exactly the direction I was going. The
-new-post.html (which as previously noted should not normally be seen by a bot) should receive a "temporary redirect" response, then the old-style .php URI should receive the 301 "permanent redirect" response. To my untrained eye, that should take care of the problem. Perhaps even take care of it in an
elegant fashion.
I'm not sure HTTP 301 is ever an appropriate response, since FT has never really moved anything permanently. If posts are deleted or the user changes the number of posts displayed per page, the resulting URL may be different. If the server issued a 301 (and didn't explicitly indicate that caching is not allowed), clients would potentially run into cases where their saved HTTP 301 redirects are pointing to the wrong locations.
For a dynamic site like FT where pages are all generated on the fly, these types of redirects should really be handled with HTTP 302/307 response codes, along with an explicit no-cache directive to ensure that the intent is clear to the browser: these redirects are ephemeral and may change at any time. Do not cache the resulting links. Always ask the server, and you will always get the right behavior.