jshttp / content-type Goto Github PK

Hi,

I have found that https://www.npmjs.com/package/content-type, the black duck is showing Thunderbird as a dependency and it is showing a license issue.

Can you confirm whether this package internally uses ThunderBird.
In the index.js file or package.json file I could not find anywhere where this is used.
Looking forward for the help.

Regards
Aditya

I'm using content-type to extract the profile parameter. According to the spec, the URI may be enclosed in either single or double quotes (or not at all). However, the current version is throwing an error in all cases except for double quotes.

Examles

let headers = [
  'content-type': 'text/html;'
];

contentType.parse(headers['content-type']);

But according to HTTP RFC, this is a legal content type.

Hi

How would you use this module for parsing content-types expecting that it might throw errors. Is it correct that you either have to try/catch or use Promise ? E.g. for synchronous usage something like this:

var parsed;
try {
    parsed = contentType.parse(type);
}
catch (e){
    console.log(type);
    console.log(href);
    console.error(e.stack);
}

I often use the request module and test against httpbin.org. This http://httpbin.org/response-headers?Content-Type=text%2Fplain%3B+charset%3DUTF-8&Server=httpbin throws the following error:

text%2Fplain%3B charset%3DUTF-8
http://httpbin.org/response-headers?Content-Type=text%2Fplain%3B+charset%3DUTF-8&Server=httpbin
TypeError: invalid media type
    at parse (node_modules/content-type/index.js:128:11)
    ...

I could solve by using decodeURIComponent, something like: contentType.parse(decodeURIComponent(type)); but is this the recommended usage?

What happens if there is no encoding specified? What happens if the encoding is invalid?

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...

• Should enforce ALPHA / DIGIT exclusively for first character in type-name & subtype-name
• Should not accept excess characters (%'*`|~)
• Should restrict length to at most 127 characters in type-name & subtype-name (1 restricted-name-first and 0 to 126 restricted-name-chars)

I am using Amazon AVS, which is returning a content type header of ":"multipart/related; boundary=------abcde123; type=application/json". The package throws a TypeError('invalid parameter format').

It appears to be the trailing "/json" which is causing the issue (manually removing it fixes the problem).

I have a docker image that includes an express server v4.18.2. It's failing on HISTORY.md every time.

4e7e0215f4ad: Pull complete
f206d87fdd12: Pull complete
5d2b14b7402b: Pull complete
85cbc4392f0e: Pull complete
77411fe1f4da: Pull complete
23f844e44e9e: Pull complete
4334efab300b: Pull complete
6496e772977a: Pull complete
3877be6b3e68: Pull complete
b65ae8fc6c48: Extracting [==================================================>] 26.25MB/26.25MB
3be3ca4d8f67: Download complete
02847af5dbd7: Download complete
4397228b905c: Download complete
docker: failed to register layer: Error processing tar file(exit status 1): lchown /node_modules/content-type/HISTORY.md: invalid argument.

index.js#L135

  var obj = new ContentType(type.toLowerCase())

According to the spec, the type and subtype are not case-sensitive, fair-enough

The type, subtype, and parameter names are not case sensitive. For example, TEXT, Text, and TeXt are all equivalent. Parameter values are normally case sensitive, but certain parameters are interpreted to be case- insensitive, depending on the intended use. (For example, multipart boundaries are case-sensitive, but the "access- type" for message/External-body is not case-sensitive.)

However, it doesn't specify that it needs to be lowercased, why make it? I was just testing with ExpressJS and saw that the content-type header's value is the only one being lowercased. It almost feels like it's the client's job to ignore the case.