On 4/24/07, Jerome Louvel <[EMAIL PROTECTED]> wrote:
[...]
> That confusion over the file- or dir-ness is *precisely* why the "add
> trailing slash" hack is done everywhere. Jerome's argument that
> disagreement is moot because of the "add trailing slash" hack is
> plenty of proof. :-)
The Reference class has no clue about whether "dir" is a file name or a
directory name or a logical resource name. It is only at the connector level
that we can get this metadata.
Understood.
The URI RFC is very clear about the way relative URI references should be
resolved, they even specify a generic algorithm:
http://gbiv.com/protocols/uri/rfc/rfc3986.html#absolutize
Just because the spec is clear doesn't mean it's right. As noted...
The Reference class implements this exact algorithm and nothing more. Now,
like the Apache HTTP Server does
(http://httpd.apache.org/docs/2.2/mod/mod_dir.html) we provide an automatic
redirection feature to prevent this unintuitive relative resolution. Note
that this is only unintuitive for URIs mapped to directories or similar
folders.
...the hack is necessary to mitigate the error.
> If directories always have the trailing slash then there's no
> (non-intentional) ambiguity. If directories don't always have the
> trailing slash then it's always ambiguous and we end up with the
> POLS-violating behavior that started this disagreement.
In general, this directory redirections shouldn't be triggered if all
representations contain hyperlinks with trailing slashes for directories.
The only case where it can be necessary is when the user manually enters the
URI or when such an URI is bookmarked.
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.
I hope this clarifies my position. Otherwise, could you concretely explain
how you would implement your behavior in the Reference class code.
I understand your position and so I shall discontinue further argument
on this point.
Take care,
John
