Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing requests with no payload #2576

Closed
matthieusieben opened this issue Jun 1, 2015 · 7 comments
Closed

Parsing requests with no payload #2576

matthieusieben opened this issue Jun 1, 2015 · 7 comments
Assignees
Labels
breaking changes Change that can breaking existing code bug Bug or defect
Milestone

Comments

@matthieusieben
Copy link

When an HTTP request that has "Content-type: plain/text" and no payload is received by hapi, request.payload is an empty object {}. It should be an empty string.

When an HTTP request w/o content-type an no payload is parsed by hapi, request.payload is an empty object {}. It would make more sense if it was null.

@devinivy
Copy link
Member

The first case certainly makes sense to me. The second case seems a little more open-ended, but intuitively it does seem like it should be falsey.

@matthieusieben
Copy link
Author

Content-type: plain/text
Content-Length: 1


(space in body) results in request.payload = " "

Content-type: plain/text
Content-Length: 0


(empty body) results in request.payload = {}

How does this makes sence ? Detecting an empty string requires to do:

if (typeof request.payload === 'object' && Object.keys(request.payload) === 0 && (request.headers['content-type'] || '').split(';')[0] === 'text/plain')

Instead of

if (request.payload === '')

or

if (!request.payload)

In the case of a route that only expects plain/text payload, the first example does not make much sence.

Plain text requests with empty bodies should also have a falsey payload in my opinion.

@devinivy
Copy link
Member

I'm sorry for the poor communication– I meant that your gripe makes sense. I agree that a plain/text request without a body should yield an empty string in hapi's request payload.

In the case of an empty content-type header and an empty body, I am less sure. Here's what the spec says:

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

@matthieusieben
Copy link
Author

All right. Damn those "SHOULD" in specs...

@arb
Copy link
Contributor

arb commented Jun 18, 2015

I believe if you set the status code to 204, you'll get the desired behavior. Never mind, misunderstood the question.

@matthieusieben
Copy link
Author

@arb, I'm not sure I understand. How would you set a status code in an HTTP request ?

@hueniverse hueniverse added bug Bug or defect breaking changes Change that can breaking existing code labels Jun 20, 2015
@hueniverse hueniverse self-assigned this Aug 11, 2015
@hueniverse hueniverse added this to the 9.0.0 milestone Aug 11, 2015
@hueniverse
Copy link
Contributor

Covered by subtext 2.0.0

@lock lock bot locked as resolved and limited conversation to collaborators Jan 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking changes Change that can breaking existing code bug Bug or defect
Projects
None yet
Development

No branches or pull requests

4 participants