Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Do not lie about what res.contentType() accepts #1047

Closed
wants to merge 1 commit into from

5 participants

@wereHamster

Passing it a literal content type string will not always work. For
application/json it works only by pure chance. It is because json is also
coincidentally the file extension. But if you tried application/javascript
it would set the content type header to application/octet-stream, because
javascript is not a known file extension.

FIXME: do I have to regenerate the html docs or can you do that for me?

@wereHamster wereHamster Do not lie about what res.contentType() accepts
Passing it a literal content type string will not always work. For
`application/json` it works only by pure chance. It is because `json` is also
coincidentally the file extension. But if you tried `application/javascript`
it would set the content type header to `application/octet-stream`, because
`javascript` is not a known file extension.
e3a5008
@curiousdannii

I've just been wrestling with this for a couple of hours. When I tracked through the source I realised there was no way it could do what guide.html had said. +1!

@mhart

I keep running into this too and every time I forget that I actually can't use res.contentType - until I actually try it and it doesn't work.

@wereHamster

So, seeing that this simple pull request was neither merged nor commented on by the repo owner, does it mean there is no interest in having accurate documentation? /me wonders...

@mhart

I wonder if you want to add to the documentation that res.contentType() just delegates to mime.lookup(), the mappings of which can be found here:

So if you want a particular content type, you might be able to find a suitable extension in there.

@brianloveswords

I think it would be better to fix res.contentType so it does what it says in the manual. If mime.lookup() can't find a type, see if it matches the string format .+/.+ and set that to the type. As a last resort, use application/octet-stream

Off the type of my head, this would break code that's doing res.contentType('mystupidpath/dumb.file') to stream some arbitrary file, but I personally I think that's acceptable.

@wereHamster

Maybe invalidates my particular case, but not the fact that the documentation is vague and the user has to dig around the source code to find out what the function actually does (or doesn't) do. Guess I'll have to update the pull request then.

@wereHamster

Doesn't seem like anybody cares about this particular problem...

@tj
tj commented

we dont even have guide.md anymore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Mar 14, 2012
  1. @wereHamster

    Do not lie about what res.contentType() accepts

    wereHamster authored
    Passing it a literal content type string will not always work. For
    `application/json` it works only by pure chance. It is because `json` is also
    coincidentally the file extension. But if you tried `application/javascript`
    it would set the content type header to `application/octet-stream`, because
    `javascript` is not a known file extension.
This page is out of date. Refresh to see the latest.
Showing with 6 additions and 4 deletions.
  1. +6 −4 docs/guide.md
View
10 docs/guide.md
@@ -785,14 +785,16 @@ Sets the _Content-Type_ response header to the given _type_.
res.contentType(filename);
// Content-Type is now "image/png"
-A literal _Content-Type_ works as well:
-
- res.contentType('application/json');
-
Or simply the extension without leading `.`:
res.contentType('json');
+Note that a literal _Content-Type_ will not always work and should be avoided.
+If you want to set the header to some exotic value, use this:
+
+ res.header('Content-Type', 'teh/lolz')
+
+
### res.attachment([filename])
Sets the _Content-Disposition_ response header to "attachment", with optional _filename_.
Something went wrong with that request. Please try again.