not support parse attachment about content HOT 5 CLOSED

@devinivy Thanks, maybe should note this in the readme.

I saw works great on its own or with other frameworks from the readme, no specific implementation specifications are mentioned, so I use this to parse attachment.

content is part of the hapi ecosystem and was designed to work seamlessly with the hapi web framework and its other components (but works great on its own or with other frameworks).

from content.

Not support attachment

GitHub Octokit return attachment; filename=name-repo-a849a73.zip, but @hapi/content can not parse it.

from content.

I realize it's not readily apparent, but disposition() is designed specifically to parse multipart form data payloads, which requires the disposition type be form-data. In the spec referenced above it notes:

Note: This document does not apply to Content-Disposition header
fields appearing in payload bodies transmitted over HTTP, such as
when using the media type "multipart/form-data" ([RFC2388]).

Here is where we use Content.disposition()— it's in pez, hapi's multipart parser: https://github.com/hapijs/pez/blob/0cf5f3031a453e7db91610c070206342e89964b0/lib/index.js#L292

If we decide to parse out the disposition type and allow other types, we would have to treat this like a breaking change and ensure pez only allows form-data.

from content.

I can see how that could easily happen. Do you think if we changed its subtitle from "HTTP Content-* headers parsing" to "HTTP Content-* request headers parsing" that it would have signaled this better? If so, I would give a PR for that change a ✅.

from content.

I can see how that could easily happen. Do you think if we changed its subtitle from "HTTP Content-* headers parsing" to "HTTP Content-* request headers parsing" that it would have signaled this better? If so, I would give a PR for that change a ✅.

Yes, I think so.

Cause this package is not a full functional http Content- parser.

from content.