On 4/30/07, Stian Soiland <[EMAIL PROTECTED]> wrote:
On 24 Apr 2007, at 16:57, John D. Mitchell wrote:
[...]
> This takes us, full circle, back to the confusion that started this
> thread originally... The implementation, and all of the consequential
> edge cases, lead to a confusing mental model of the expected behavior.
> This specific example of adding a "sub" reference to a
> "http://some.com/dir"; gives the erroneous answer of
> "http://some.com/sub"; rather than "http://some.com/dir/sub";.
>
> As you noted, if the directory is "always" (re)written to the proper,
> normalized form "http://some.com/dir/"; then the expected behavior is
> kept. Great but that doesn't lessen the confusion for developers who
> have to keep this extraneous complicatification in mind and make sure
> their code works regardless.
How do you suppose a client to know if a relative link in a
representation retrieved from http://some.com/dir to "sub" is to
"http://some.com/sub"; or "http://some.com/dir/sub";? You would need
some new magical headers (WebDAV-ish) to say that the resource is a
collection or you need to hard-code this knowledge in the client
(which would make it harder to change http://some.com/someresource
into a collection later when you want to add http://some.com/
someresource/morestuff)
Indeed, that's exactly the problem -- we can't know. That means that
standard is backwards: "http://some.com/whatever"; + "something" ->
"http://some.com/whatever/something";.
I don't see a big point in exploring how this could have been done
differently, URLs have existed for a long time already and I believe
you need a better reason than "I don't want to generate the right URI
to the collection (ie. with trailing /) in the first place!" to go
outside the expected and normal behaviour.
But that's exactly what the redirect hacks are all about. The
expected behavior is clear and clearly violated by the standard
behavior and so people have to do the hack precisely to match
everyones expectation.
Take care,
John
