[Drop.io API] Chunked encoding

[Aleksandar Vidakovic]

Salut all,

does drop.io accept chunked encoded POSTs? I am having some troubles
uploading files with that encoding... and it seems that I have no
influence on this behavior in my environment (Java ME).

Thanks in advance for any help.

Cheers,

Aleks

--
You received this message because you are subscribed to the Google Groups "Drop.io API" group.
To post to this group, send email to dropi...@googlegroups.com.
To unsubscribe from this group, send email to dropio-api+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dropio-api?hl=en.

[Jake Good]

Aleks:

My gut would say that No, we don't support chunked encoding, only
because I'd have to test and play around with it more...

Here's the official documentation on how the uploading works:

http://dev.drop.io/rest-api-reference/actions/create-a-file/

Typically on Java playforms, the uploading component will not send
along the filename parameter and it fails. I would try that.

Otherwise, if you would send an example dialog (like the one at the
end bottom of that url) that would be fantastic!

Jake Good
http://dev.drop.io

[Aleksandar Vidakovic]

Hi Jake,

I did a bit more research on that problem and found the following blog
post about Nginx and chunked encoding:

http://lisp-univ-etc.blogspot.com/2009/04/correcting-content-encodingchunked.html

So it seems to be a known problem. I don't know if it has been already
fixed in newer versions (probably not).

After reading this I decided yesterday night to implement a custom
"light weight" (i. e. not a full featured lib like commons-httpclient).
I needed some customization anyway for PUT and DELETE (as these are not
available in Java ME)... and with that I was able to upload any file
which means that my immediate problem is solved.

Nevertheless, please find attached a sample dialog (request.txt,
response.txt) with chunked encoding (I was using the Sun WTK 2.5.2
emulator on Linux). As far as I remember the emulator sends data in
packets of 2048 bytes. The file I was sending is a text file of ~4K.

As you can see in the request there is no "Content-Length" header entry
and it seems this is what Nginx is complaining about. Although - as of
HTTP 1.1 (I think) - leaving out this header entry is allowed and should
be handled by a compliant server. Actually, I explicitly set the content
length before sending the request, but it seems that the client side
(emulator) HTTP implementation removes this automatically.

Thanks again for your help.

Cheers,

Aleks

[Jake Good]

Thanks for all the information! Glad you got a working solution...
I'll add this to our internal bug tracker so that we don't loose site
of it.

Thank you again...

Jake Good
http://dev.drop.io

> <request.txt><response.txt>