Content Negotiation and paths.

[karlcow]

Currently according to route, the content type is hardcoded in the path root. Is there a reason to have chosen that design over an extension? It also makes it a bit more complicated when it comes to map content-negotiation of a server where the server path is /something/blah and blah can be in different formats depending on what the HTTP client is requesting.

[alicoding]

Hi @karlcow

We might not have thought of the way you suggested here for extension over hardcoded content type root path. Initially we want to have a path that will serve files the same way as Unix-like file system where you specify anything of the root server it should just do a simple listing (this is obvious to you I'm sure).

As to content-negotiation I'm sure @humphd will have better answer for this as we never thought of doing that initially, but again what you have suggested here might be something we can implement as I can see the benefit for having this as well.

This might not totally answer your question, but I just want to give you a bit details and maybe @humphd can give you a full/correct answer as to why we have chosen this design.

[humphd]

What we have now with these routes developed out of a need for testing--it isn't final for sure. The /p/ route wants to act like you'd expect a regular httpd to do, and tries to do content negotiation based on extension, see https://github.com/mozilla/makedrive/blob/master/server/lib/filer-www/default-handler.js#L26-L36. There's more to be done there, for sure.

The /j/ and /z/ routes do some non-standard things (e.g., recursive listing data of directories), so I wanted to separate them out from /p/. Maybe I'm wrong, and doing this via headers from the client is a better solution?

Building out and improving the filer-www stuff needs to happen, so this ticket can serve as a starting point. If you have suggestions, toss them in here. Thanks for filing.

[alicoding]

We will do another triage once we add another milestone, but will push this out of this milestone for now.

[gideonthomas]

@humphd I think allowing the client to set the Accept header (default can be based on file extension) to get json or gzip or whatever format they would like makes sense because I don't really think there is a use case where an end-client would want to manually set that header. I think that only an app that would use makedrive as a backend would want to GET files in different formats and it probably makes more sense to do it via headers.