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
Milestone

Comments

@matthieusieben
Copy link

@matthieusieben matthieusieben commented Jun 1, 2015

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

@devinivy devinivy commented Jun 17, 2015

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

@matthieusieben matthieusieben commented Jun 18, 2015

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

@devinivy devinivy commented Jun 18, 2015

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

@matthieusieben matthieusieben commented Jun 18, 2015

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

@arb
Copy link
Contributor

@arb 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

@matthieusieben matthieusieben commented Jun 18, 2015

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

@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

@hueniverse hueniverse commented Aug 11, 2015

Covered by subtext 2.0.0

@hueniverse hueniverse closed this Aug 11, 2015
@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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants