Parser for x-www-form-urlencoded appends newline to parameter value

[pteetor]

This code fragment parses a simulated POST request with one parameter. It appears that the parser is appending an unwanted newline (\n) to the parameter value.

fake_post <- fiery::fake_request(
  'http://example.com/test',
  method = "post",
  content = 'id=34632',
  headers = list(
    Content_Type = 'application/x-www-form-urlencoded'
  )
)

post_req <- Request$new(fake_post)
post_req$parse(`application/x-www-form-urlencoded` =
               parse_queryform() )
post_req$body

The output is:

$id
[1] "34632\n"

Notice that the id value has a trailing newline (\n), which seems wrong.

For a two parameters POST, the newline is appended to only the second parameter, not the first.

[thomasp85]

Hmm... That parser is taken directly from webutils. @jeroen is this expected behaviour?

[jeroen]

No:

> webutils::parse_query('id=34632')
$id
[1] "34632"

[thomasp85]

but if the body ends in a newline it will become part of the value. I can easily fix this in reqres, but I wonder if you wouldn't want to strip newline from the input in webutils?

[jeroen]

If the body ends with a newline, that newline is actually part of the value. You shoudn't ignore it, it might be important :)

[thomasp85]

That's a fair sentiment :-)

[thomasp85]

All this really comes from the fake_request mock in 'fiery' which adds a newline (can't remember why I chose to do that) to the body, so it has nothing to do with reqres

[pteetor]

Ah ha! Thank you very much for the diagnosis.

Also, a general, big Thank You for this package. It's a great addition to our toolkit of web server code for R.

[thomasp85]

No problem. Are you planing on using it in prairie?

[pteetor]

Yes, I'd like to use reqres in prairie. Until now, there's been no real support for the POST method in prairie, and reqres appeared at just the right moment to fill that gap.

I am only a package contributor, not the owner, however. So I need to clear my plan with the owner, Nate.

[thomasp85]

That would be great. The reason for splitting up the whole fiery foundation into fiery, routr, and reqres were exactly so that routr and reqres could become specs of their own and be used in other projects...