Hi,
Preethi Natarajan wrote:
If
requests are pipelined, Firefox should not assume that data from
subsequent read()s on the socket belong to the same response.
Hm? With normal HTTP 1.1 pipelining, responses aren't interleaved, so
until a response has been completely received, susbsequent reads do
belong to the same response...
- NSPR communicates the SCTP stream number on which a request was
written to the HTTP protocol module. The SCTP stream number is unique to
a HTTP Transaction, and should be stored somewhere, perhaps in
nsHttpTransaction. Transfer of this stream number could be via a new
method - WriteOnSCTPStream() (in nsOutputStream) that is very similar to
Write(). WriteOnSCTPStream() just has an extra pointer argument, where
the callee writes the SCTP stream information.
In my opinion, it is a mistake to add STCP stream numbers to input
stream interfaces. Why not store the stream ID somewhere near socket
transports? That way, a socket transport (or a new class SCTPTransport
perhaps?) would belong to a single stream in a SCTP stream. Multiple
SCTP transports could belong to the same underlying socket.
Does that make sense?
Another possibility might be to provide the stream ID to
open{In,Out}putStream.
- nsHttpTransaction accepts the response from nsInputStream only if the
response came on the SCTP stream it stored as mentioned above.
The suggestion above would mean that the HTTP code would need very few
changes, only in connection setup.
I chose nsHttpTransaction as the point to do these modifications since
nsHttpTransaction is an atomic request-response transaction entitiy.
Maybe the modifications should move closer to NSPR than
nsHttpTransaction? Maybe I should take a completely different route to
achieve what I need?
Since SCTP provides generic stream support, as far as I can tell, and
since nsITransport does the same, it seems better to use those
interfaces instead, as suggested above.
- In case of pipelining n requests, I assume n instances of
nsHttpTransaction are created. Is that right?
Yeah, that's correct.
- Does the implementation use the Content-Length field in the resonse
header to demarcate the end of a response?
Basically yes (if present). However, in case of chunked encoding, the
chunked EOF marker indicates end of response. I'm not sure what happens
in a non-keepalive connection if the Content-Length is shorter than the
number of bytes the server sends before closing the connection.
-christian
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
