Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#11687 closed bug (fixed)

BHttpRequest retrying a POST/PUT request should reuse the same stream data

Reported by: puckipedia Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Network Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Now, when e.g. a Location: header or a 401 response is gotten and BHttpRequest retries the request, it doesn't reuse the written bytes from previous request, but reads the same amount again, possibly resulting in crashes or unwanted data being sent to the server. This could be fixed either by using BPositionIO, or caching the data internally.

Change History (4)

comment:1 by pulkomandy, 10 years ago

Caching the data is not an option, the use of a BDataIO is on purpose and makes it possible to have a lot of data (streamed from a file for example) without using too much RAM. So a BPositionIO is needed here.

comment:2 by pulkomandy, 10 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev48611.

comment:3 by axeld, 10 years ago

I'm not sure this is a good solution. Now, the request will behave irrationally on a redirect when you use a non-seekable stream.

One would need some kind of callback mechanism in order to deal with that case (and eventually reset the input stream manually there). It might also be interesting for the initiator to know whether a redirect happened or not, in any case.

Also, if we had a specific callback for the rewind case (which could default to rewinding a seekable stream), we could also add buffering the input data up to a certain size at any time.

Last edited 10 years ago by axeld (previous) (diff)

comment:4 by pulkomandy, 10 years ago

You could use one of the existing callbaks to detect redirects already. ConnctionOpened and HostnameResolved happen early enough for this. In the case of non-seekable streams you probably need to tear down the whole object and build a new one.

Detecting redirects canbe done in several ways, a common one is testing for position == 0 in the DataReceived callback (but several other callbacks can be used). Automatic redirect following can also be disabled if more finegrained control of the redirects is needed (WebKit currently does this for example, as it needs to update the URL shown to the user as the redirects happen).

I'm not sure a buffer is a good idea, the redirects always happen after the whole data is sent anyway. It's possible to wrap a BPositionIO with a BBufferIO if you need/want buffering.

Note: See TracTickets for help on using tickets.