QHttp file upload doesn't stream?

[danc81]

The same will happen with QNetworkAccessManager, it seems that the QSslSocket buffers all the data first.

[haughki]

The same will happen with QNetworkAccessManager, it seems that the QSslSocket buffers all the data first.

Yes indeed. Haven't solved that problem yet, but absolutely: it's SSL that's causing the problem.

Also, fwiw, I did try QNetworkAccessManager and had exactly the same problem...

Hawkeye Parker

[danc81]

I've tracked it down to the fact that when QNativeSocketEnginePrivate::nativeWrite() calls WSASend() it returns SOCKET_ERROR and the reason is WSAEWOULDBLOCK, now this appears to be because under normal HTTP, only chunks of 4096 are sent which are fine but using SSL, chunks of 30kB are sent which causes the socket to still be busy on the next attempt. This is find expect that somewhere it seems to report that the bytes were sent and read more from the input device.

That is as far as I've got with it.

[haughki]

I've tracked it down to the fact that when QNativeSocketEnginePrivate::nativeWrite() calls WSASend() it returns SOCKET_ERROR and the reason is WSAEWOULDBLOCK, now this appears to be because under normal HTTP, only chunks of 4096 are sent which are fine but using SSL, chunks of 30kB are sent which causes the socket to still be busy on the next attempt. This is find expect that somewhere it seems to report that the bytes were sent and read more from the input device.

That is as far as I've got with it.

Thanks: good to know; haven't gotten that far. We're going to have to solve this problem one way or another. I'll certainly update this post when I know more. We also have some sense that there should be a way to better configure/build OPENSSL at the client to get around this. Currently still in Google land....

[danc81]

I don't think the problem lies with OpenSSL, I think the problem is wherever the uploadProgress() signal is fired from is incrementing the number of bytes by what should have been sent and not what was actually sent. If this is corrected (in theory a one-liner), it should at worst fire the signal too many times but with the correct information. This is only my theory and I have yet to prove it...

[mgoetz]

Hi,

I have the following patch for Qt 4.5.x: http://pastebin.ca/1619204
It should apply to Qt 4.6 too.
Could you please see if your issues are solved by this?

Markus Goetz

[mgoetz]

If you are not using QHttp but QNetworkAccessManager, there is a 4.5.x patch out too.

[haughki]

Hi,

I have the following patch for Qt 4.5.x: http://pastebin.ca/1619204
It should apply to Qt 4.6 too.
Could you please see if your issues are solved by this?

Markus Goetz

Hi Markus et al.,

We applied the patch on 4.5.2, and in "basic testing" streaming seems to be working fine now over SLL using QHttp.

Thanks _so_ much for this patch, Markus. It's saved us a pretty big chunk of work.

We'll be testing the patch more thoroughly in the coming weeks (as part of our normal app testing), and we'll post here if anything bad comes up.

One note: I'm not expert with patch, but the diff you posted didn't patch smoothly for me. I ended up applying the patch manually. E.g.:

C:\QHttpPatch>patch --dry-run < qhttp_patch.diff patching file qhttp.cpp Hunk #3 FAILED at 2660.
Hunk #4 FAILED at 3119.
2 out of 4 hunks FAILED -- saving rejects to file qhttp.cpp.rej

The diff looks good to me, so I don't know why patch is complaining about hunks #3 and #4. In any case, it was very straightforward to apply the changes manually.

Thanks again,
Hawkeye Parker