Handling of trailing '/' in paths

[adamretter]

Should either or both of the following be valid? Is there a difference?

rest:path("/a/b/c")

rest:path("/a/b/c/")

If we only have rest:path("/a/b/c"), which is the current in the eXist implementation, should we match the URI "/a/b/c/" sent by the browser or not?

Do we want manual control over this, or is there some sort of standard already?

[ChristianGruen]

I would recommend to treat /a the same as /a/ (and even a and a/). This is what we currently do in BaseX, and I believe it’s how our users write RESTXQ, as they are used to it when retrieving web pages.

[adamretter]

Christian,

Do you allow both forms in the rest:path syntax?

[ChristianGruen]

Yes, we do.

[adamretter]

Okay I have done a bit of reading into this. It appears that from a Client perspective it is important not to treat /a the same as /a/, there are various reasons for this including SEO. It is instead recommended rather than just to serve the same content from both URI, rather to 30x redirect one to the other.

I also now think the direction of redirection is important. Basically a trailing '/' should indicate a directory listing like thing. Whether such a thing explicitly exists in the Resource concept of REST I am not sure. I guess its just resources all the way down, if that is the case we should not permit a trailing '/' at all. I suspect thins needs further thought out yet, and ultimately should be selectable by the developer on a function by function basis.

[ChristianGruen]

It’s true that there is some semantic difference when passing a URL to the browser with or without slash; in the latter case, a web server will add a slash and send a redirect to the client if the resource cannot be resolved.

Regarding RESTXQ, I’m not sure what (missing) trailing slashes could indicate, or how a sensible distinction would look like. In JAX-RS, both variants seem to be allowed: “The JAX-RS runtime parses URI path templates the same whether or not they have leading or trailing spaces.” (http://docs.oracle.com/cd/E19798-01/821-1841/ginpw/)

[adamretter]

Hmm. I am not sure that all web-servers do this redirect automagically. Do you have a link to one that does or an appropriate standard?

[ChristianGruen]

Afaik, this is usually done via rewrite rules (using the RewriteRule directive).

[jb8748]

This has just come up on the BaseXTalk list with a couple of experiences.

For me the important point is not what slashes or not means in the world of RESTXQ and resources but what they mean to the browser.

/restxq/dba to a browser means I'm in the restxq directory and I'm showing the file dba.
/restxq/dba/ to a browser means I'm in the dba directory and I'm showing a file listing or the default document.

This becomes really critical if what you want to do is redirect the browser using relative paths. If I say redirect to ./databases (the directory databases within the current one) then the two examples above give different results.

/restxq/databases
/restxq/dba/databases

As I understand it, with the current implementation in BaseX at least, you can't set for different things to happen depending on the slash. (Here I'd want one to redirect to ./dba/databases and the other to ./databases)

My suggestion would be to make the trailing slash significant.

I don't think it will make a difference for a lot of cases (where people are using page names with .htm for example and people don't add a slash by mistake) but it makes it possible to distinguish in those cases where it's important.

If you want to return the same response for both you can

1. add both in the annotations.

declare
%rest:path("dba")
%rest:path("dba/")
function _:index() {

... };

2. You can have a function to catch one and redirect to the other.

declare
%rest:path("dba")
function _:redirect() {
web:redirect('dba/')
};

declare
%rest:path("dba/")
function _:index() {

... };

3. Perhaps we should have an option that for any file requested (no slash) that would return a 404 but that would have matched if it had a slash the browser is automatically redirected. Perhaps this could be set on a server, module or function level. Or add it as an option to %rest:path(path, autoredirect).

declare
%rest:path("dba/",true())
function _:index() {

... };

The advantage of redirecting rather than just having two rest:path entries is that you can be sure relative URLs (to scripts etc) will be correct whichever way a user made the first request.

Just my thoughts, thought I'm sure I've missed some cases.

[joewiz]

+1 to sane defaults and consistent behavior!