The asynchronous listener had no reliable way to access HTTP result and
headers from the callbacks. As the callbacks are triggered
asynchronously, they can be run after the request has carried on and,
for example, followed an HTTP redirect, clearing its internal state.
The HeadersReceived callback now passes a reference to BUrlResult for
the request. There are two cases:
- Synchronous listener: passes a reference to the request's results
directly
- Asynchronous listener: archives a copy of the result into the
notification message, and passes a reference to the unarchived copy.
Unfortunately this comes with several ABI and API breakages:
- Change to the prototype of HeadersReceived()
- Change to the class hierarchy of BUrlResult (implements BArchivable)
All users of HTTP requests will need to be updated if they implemented
in HeadersReceived or used BUrlResult.
* BUrlResult is back, with ContentType and Length methods.
* BHttpResult subclasses it and use HTTP header fields to implement
those
* Introduce BDataRequest for "data" URIs. These embed the data inside
the URI, either as plaintext or base64 encoded.
* Remove the fRawData field, as handling it is too complicated (it's
not easy to have proper copy semantics on a BDataIO) and it's not used
anyway, as the listener DataReceived call is enough to get the data and
handle it.
* All the remaining fields are HTTP-only, so rename the class to
HttpResult and attach it to HttpRequest instead of UrlRequest.
Adrien Destugues