search

jshttp / content-type

Create and parse HTTP Content-Type header
MIT License
131 stars 25 forks source link

Content-Type checking less restrictive than RFC 6838 spec #10

Closed bbamsch closed 7 years ago

bbamsch commented 7 years ago

According to RFC 6838 spec, content-type naming should follow ABNF format as shown...

Type and subtype names MUST conform to the following ABNF:

type-name = restricted-name
subtype-name = restricted-name

restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first  = ALPHA / DIGIT
restricted-name-chars  = ALPHA / DIGIT / "!" / "#" /
                         "$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; Characters before first dot always
                             ; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always
                             ; specify a structured syntax suffix

Current (as of commit c9da3ac) content type regular expression is less restrictive than specified above.

For example, the following characters are considered valid during type checking while they do not appear in RFC 6838:

To conform with RFC 6838 spec, the following changes should be made...

dougwilson commented 7 years ago

You're right, and that is intentional; this is a RFC 7231 parser, and RFC 7231 defines it less restrictive. You'd be interested in the https://github.com/jshttp/media-typer module :) which is a RFC 6838 parser.

bbamsch commented 7 years ago

Aha, the confusion came from the docstring standing above the regular expression. See: https://github.com/jshttp/content-type/blob/c9da3ac941b642b80f2110a240e6f2c2d447534f/index.js#L41

The docstring improperly references RFC 6838. I can put together a quick patch for updating the comment.

dougwilson commented 7 years ago

Yes, I was just looking at your link :) The comment is indeed wrong, and if you'd like to patch it up, I'd absolutely accept 👍

dougwilson commented 7 years ago

It should say "RFC 7231 sec 3.1.1.1"