Getting the request body about httpuv HOT 25 CLOSED

I believe env$rook.input$read() should give you a raw vector with all the data.

from httpuv.

No need to pass it an argument?

from httpuv.

I don't remember about rook in general, but for httpuv, the default value is -1 which means return everything.

from httpuv.

OK I got it to work now. The problem was that I was unaware that the rewind() method needs to be called before being able to read the data.

from httpuv.

Hmmm, you shouldn't need to call rewind() first. Is there a bug?

from httpuv.

There is some funky stuff going on. Also it doesn't work consistently if I upload some (larger) files. Could it be that some buffer is not properly cleared in between requests or so?

from httpuv.

It's certainly possible. How large?

from httpuv.

And what version of Rcpp do you have installed?

from httpuv.

It happens occasionally (not consistently) when uploading files of +/-
10MB. I have Rcpp_0.10.3 right now. I'll upgrade it.

On Fri, Jun 14, 2013 at 3:48 PM, Joe Cheng [email protected] wrote:

And what version of Rcpp do you have installed?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-19485726
.

from httpuv.

I updated Rcpp and httpuv and at least part of the problem seems to have disappeared...

from httpuv.

In my own tests I couldn't find any problem when conducting requests serially, even with requests that are hundreds of MB. However there appear to be a quite serious bug in concurrent uploads that I had not detected until now. I'll get it fixed ASAP. Thanks!

from httpuv.

Just to clarify: I am writing a multipart/form-data parser and it works fine most of the time, but for sometimes when I do a request in chrome (usually though an iframe in the browser) the input seem contains nothing but jibberish. Could it be that the request body is gzipped or so? Otherwise it might be a bug in chrome.

from httpuv.

It's possible. You could check for the header, then ungzip it in R just to
see if that fixes it. If so we can see about handling that transparently in
httpuv.

On Fri, Jun 14, 2013 at 8:18 PM, Jeroen [email protected] wrote:

Just to clarify: I am writing a multipart/form-data parser and it works
fine most of the time, but for sometimes when I do a request in chrome
(usually though an iframe in the browser) the input seem contains nothing
but jibberish. Could it be that the request body is gzipped or so?
Otherwise it might be a bug in chrome.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-19490474
.

from httpuv.

gzcon has an allowNonCompressed flag that should let you always wrap it, at least for testing.

On Fri, Jun 14, 2013 at 10:29 PM, Joe Cheng [email protected] wrote:

It's possible. You could check for the header, then ungzip it in R just to
see if that fixes it. If so we can see about handling that transparently in
httpuv.
On Fri, Jun 14, 2013 at 8:18 PM, Jeroen [email protected] wrote:

Just to clarify: I am writing a multipart/form-data parser and it works
fine most of the time, but for sometimes when I do a request in chrome
(usually though an iframe in the browser) the input seem contains nothing
but jibberish. Could it be that the request body is gzipped or so?
Otherwise it might be a bug in chrome.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-19490474
.

from httpuv.

Hmm so the problem is not gzip, turns out the request body is just truncated. It's really strange, it only happens for chrome + httpuv. It doesn't happen in firefox or using rhttpd. I'll try to debug it a bit further.

from httpuv.

What version of Chrome? What operating system?

On Sat, Jun 15, 2013 at 1:04 PM, Jeroen [email protected] wrote:

Hmm so the problem is not gzip, turns out the body is just truncated. It's really strange, it only happens for chrome + httpuv. It doesn't happen in firefox or using rhttpd. I'll try to debug it a bit further.

Reply to this email directly or view it on GitHub:
#8 (comment)

from httpuv.

It happens on all chrome, in all three OS (Linux, Win, OSX). It's tricky to reproduce, because it only seems to happen when I post a form targeting an iframe (ajax does not support file uploads). Maybe it's just something funky on chrome that somehow is triggered by headers from httpuv or so.

from httpuv.

I'm having such a hard time narrowing this down. In case you want to reproduce:

install_github("ocpu", "jeroenooms")
library(ocpu)

Should popup two browsers. In the httpuv one, fill out the fields as shown in the picture and click the 'iframe' button. For debugging purposes, a file containing a dump of the request-body of each POST request is saved on your desktop.

from httpuv.

I just installed the latest version from github and I think the problem has disappeared with your latest fix.

from httpuv.

Ok great. That would make sense as the bug I fixed would've resulted in truncation.

​Sorry for the inconvenience!

On Sat, Jun 15, 2013 at 2:26 PM, Jeroen [email protected] wrote:

I just installed the latest version from github and I think the problem has disappeared with your latest fix.

Reply to this email directly or view it on GitHub:
#8 (comment)

from httpuv.

Thanks for the quick fix :-) Closing this issue now. PS: will you be in Spain for user 2013 next month?

from httpuv.

Yes, you?

from httpuv.

yes :) See you there.

On Sat, Jun 15, 2013 at 3:48 PM, Joe Cheng [email protected] wrote:

Yes, you?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-19504757
.

from httpuv.

Is there an easy way to build this new version for windows? I would like to test it on win, but I can't get it to compile.

from httpuv.

Ah I just discovered Uwe's win-builder service :-) Here is a copy of the win build for R 3.0.1 if someone else is interested: http://www.stat.ucla.edu/~jeroen/httpuv_1.0.6.99.zip

from httpuv.