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.

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.

Anyway, this isn't a strong objection. I will defer to the others on the team.

- Brian
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network

Reply via email to