7 ms·
That's what permanent means. "Adjective permanent Without end, eternal. Lasting for an indefinitely long time. " Also, "This response is cacheable unless indi
by Piskvorrr 11y ago
That's what permanent means.
"Adjective
permanent
Without end, eternal.
Lasting for an indefinitely long time.
"
Also, "This response is cacheable unless indicated otherwise," says RFC 2616.
Working as designed, IMNSHO. Perhaps not working as intended, but alas, that's a case of ¬RTFM.
- Typhon 11y agoThis seems yet another example of web professionals not understanding HTTP. Much like webpages that say "404 not found" with a "200 OK" header.
- manyxcxi 11y agoIn their defense that is probably the case of their MVC framework or CMS returning a 200 after not being able to match the route and not really them doing it on purpose. But yeah, I agree- (though I've missed them I'm sure) I pretty voraciously make sure my HTTP status matches my intended response- and sometimes that means you've got to write the code in the controller that tells the request to specifically return a certain status.
- Piskvorrr 11y agoThat just pushes "web professionals not understanding HTTP" one level down the stack, except this "web professional" is not the user doing the clicky, but whoever made the framework; the problem remains unchanged.
- lmm 11y agoSometimes it's a disagreement over what it's reasonable to expect from a framework user. Framework developers expect the users to read their docs and use their API only the way that's documented. Users expect any given API method to do what it says.
- jrumbut 11y agoI would say this falls under web professionals not understanding their framework, which is at least as common a problem as not understanding HTTP.
- manyxcxi 11y agoHeck, it might even be more common. Especially when you talk about huge frameworks like Spring for Java. Also, with CMSes like Wordpress I imagine you can't really change the status that easily if it's not returning what you'd expect. I'm not saying a WP 404 page DOESN'T return 404, but if it returned 200, how far would you have to dig to change that? If my CMS wasn't doing it exactly right, I would probably just shrug and move on unless it was critically important to something I was writing against it.
- mattmanser 11y agoStupid protocol decisions are still stupid protocol decisions no matter how much you condescendingly try and blame the user.
- davesque 11y agoIs the status line technically a header?
- Filligree 11y agoNo.
- Piskvorrr 11y agoRequest (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body. /quote RFC2616 (So, the status line is an entity of its own, which is followed by headers.)
- davesque 11y agoThat's what I thought.
- deleted 11y ago[deleted]
- _yy 11y agoMaybe it's bad design, then?
- Piskvorrr 11y agoAt least on three counts - in user agents, in crawlers and in RFC: - I definitely see bad design in interpreting the RFC as "if no caching metadata, then cache forever;" this violates Principle of Least Astonishment. - Also, "301 and 302 has completely different meaning to a crawler" seems illogical. - Perhaps the RFC should have also specified something like "in absence of caching headers, don't assume 'cache forever', that is a long time"; it does not try too much to prevent implementors from shooting themselves (and users) in the feet.
- donatj 11y agoPermanent meaning anything other than permanent violates the Principle of least astonishment.
- Piskvorrr 11y agoSee my original post - permanent Permanent Redirect works as designed ;) I was later trying to point out possible ambiguities in how the spec is interpreted vs. how it's written. In defense of the browsers - the RFC does say, in essence, "rewrite the 301'd URL and be done with it," so the browser does not even need to deal with the redirect any more.
- kedean 11y agoI would argue that your statement is only true as long as the URL in question is owned by the application that sent the 301 in the first place. If a different application now owns the URL, then it violates least astonishment for the URL to be redirect when, from it's perspective, the redirect was never sent. At the least, a redirect should not be permanent across name server changes (when the domain changes hands). Unfortunately, this would effectively be adding state to HTTP.
- kzrdude 11y agoIt's unreasonable to cache it for longer than a very long time (3 months or so). Nothing in "cache" says permanent storage.