On 2012-01-14 00:04, Brian Smith wrote:
Julian Reschke wrote:
I don't think it is very important, and I am generally opposed to
making minor new features to HTTP like this unless they have a
major benefit, because they end up creating compatibility problems
because there will always be products that take forever to support
the addition. So, I am leaning towards saying "nope, do not want."
Which is an argument for never making changes :-)
I am saying that the bar of "this warrants a change to the standard" must be
pretty high--but, not impossibly high.
Apache mod_dav for instance redirects requests to WebDAV collections
if the URI doesn't have a trailing "/" (to the preferred URI with the
"/"). Right now that happens with a 301, as far as I recall.
Right. I am saying 307 is good enough. If the client doesn't like the negative aspects of doing that redirect
so often, then the client should be changed to add the slash. According to HATEOAS, this should just involve
changing one link in one document that the client has been pointed to or indirectly navigated to. And, if the
client implements 307 and has a persistent cache, it will basically effectively do for a 307 what it would
have done for a 308, right? Just, when its cache gets cleared, it will have to re-follow the link. But, that
isn't such a bad thing. If the server stopped redirecting "foo" to "foo/" at some point
then it is probably better to listen to what the server is saying *now* (as opposed to what it told you to do
"permanently" in the past) anyway.
Nice try that you cite HATEOS, but we're having an HTTP dicussion :-).
A WebDAV client may not even be capable of being reconfigured (short of
changing the code). But the server should still have the capability to
tell the client: "look, next time you ask please use the new URI in the
first place".
Also, as a matter of fact, Firefox treats all redirects as permanent as
far as the spec is concerned. For instance, when you save a bookmark for
a redirect page, it uses the redirect URI, not the original URI (even
for 302).
Or, in other words, the definition of "permanent" is weak to the point of not being
useful as a standard. If developers of every product have to decide what "permanent"
means for their product (if anything), then you don't really have a standard. 308 vs 307 better
describes the server's (current) intention to people, but software can't really interpret that
intention in a useful way.
I think the intention defined in the spec is pretty clear, no?
...
Best regards, Julian
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
