search

dylan-lang / http

HTTP server and client for Dylan
https://opendylan.org/package/http
MIT License
22 stars 11 forks source link

default-content-type not specialized #59

Closed kibook closed 10 years ago

kibook commented 10 years ago

f83e9d44a4cd1bceb88a1fc7c6a1b28488a953a9 allows default-content-type to return either a <mime-type> or a <string> (and specializes to <string> with "application/octet-stream"), but locator-media-type for <directory-resource> here expects only a <mime-type>.

Add a specialized default-content-type method for <directory-resource> which returns a new <mime-type> of application/octet-stream

waywardmonkeys commented 10 years ago

I'm going to leave this one for @cgay to take a look at.

kibook commented 10 years ago

I am mostly trying to figure why <directory-resource> is giving me trouble, examples using it (examples/web60/static-content.lid, and the static-content tutorial in the documentation) signalled "application/octet-stream" is not of type {<class>: <mime-type>} and would not list the directory or serve any files.

The change here has stopped that error when I run the example library, and the directory listing seems fine, but files signal an error:

No applicable method, applying {<incremental-generic-function>: write-element} to {<simple-object-vector>: {<response>}, 122}. No applicable method, applying {function 0xfb850} to #[{<response> 0xa1b730}, 122].

I noticed changing copy-to-end in serve-static-files (server/core/static-files.dylan) from copy-to-end(in-stream, response) to copy-to-end(in-stream, response.response-stream) will serve files as expected, I'm not sure if that is a proper solution, however.

waywardmonkeys commented 10 years ago

I agree that things have to be done and a couple of things need fixing. :) Just that @cgay is the best person as he's most familiar with the code.

If you could drop by #dylan on irc.freenode.net, it would be useful / helpful perhaps.

cgay commented 10 years ago

I don't remember why I thought it was a good idea to allow content types to be either <mime-type> or <string> but that seems questionable to me now. Especially given that the Content-type header really accepts a "media type".

I suspect the right thing is to make default-content-type always return a <byte-string> or always return a <media-type>. The latter feels kind of heavy to me, in that it imposes more burden on programmers to simply want to stuff "text/plain" in the Content-Type header, and it is certainly less efficient.

kibook@, do you want to look at changing default-content-type to always return a <byte-string>?