Activating a connection/dispatching a transaction

[Josh Matthews]

Digging around in the low level networking stuff, I have some questions:

What does it mean for a connection to be activated (ie.
nsHttpConnection::Activate)? What would a connection not be activated?
What does it mean for a transaction to be dispatched?

The context for these questions is that I'm trying to figure out how
Gecko decides what to do with the residual bytes left over from an HTTP
response to a FETCH request, where the response contains a non-empty
body in violation of the spec. It appears that Activate discards any
bytes that were pushed back into the connection, but what guides this
decision?

Cheers,
JOsh

[Patrick McManus]

On Mon, Aug 31, 2015 at 3:47 PM, Josh Matthews <jo...@joshmatthews.net>
wrote:

> Digging around in the low level networking stuff, I have some questions:
>
> What does it mean for a connection to be activated (ie.
> nsHttpConnection::Activate)?

Activate() gives a connection control of a transaction. That connection
might have been idle (alive but with no transactions) or if it is spdy/h2
it might have other transactions already running on it.

> What would a connection not be activated?

When it has connected but has not yet carried any transactions.. or when
its transactions are complete but it is kept alive waiting for more.

> What does it mean for a transaction to be dispatched?
>

To dispatch a transaction means the connection manager is asked to take a
new transaction and figure out whether it can be run now and if so how (and
if not to queue it). So a transaction that fits an idle connection can be
immediately activated per the paragraph above.. but if there is no
connection that can accept it the transaction needs to go into a queue and
a new connection needs to be started, unless there are too many connections
already in which case it waits.. etc.

>
> The context for these questions is that I'm trying to figure out how Gecko
> decides what to do with the residual bytes left over from an HTTP response
> to a FETCH request, where the response contains a non-empty body in
> violation of the spec. It appears that Activate discards any bytes that
> were pushed back into the connection, but what guides this decision?
>

We just consider it framing garbage and do our best to skip over it looking
for the next stream. I think we sometimes give up and close the stream.
Indeed, its a protocol mistake on the part of the sender.

hth

[Josh Matthews]

On 2015-08-31 4:14 PM, Patrick McManus wrote:
>> The context for these questions is that I'm trying to figure out how Gecko
>> decides what to do with the residual bytes left over from an HTTP response
>> to a FETCH request, where the response contains a non-empty body in
>> violation of the spec. It appears that Activate discards any bytes that
>> were pushed back into the connection, but what guides this decision?
>>
>
> We just consider it framing garbage and do our best to skip over it looking
> for the next stream. I think we sometimes give up and close the stream.
> Indeed, its a protocol mistake on the part of the sender.
>
> hth
>

Thanks, that's helpful. Do you know where the logic described above
resides in the code?

Cheers,
Josh

[Patrick McManus]

for a persistent h1 connection
https://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpTransaction.cpp#1427

for a non persistent h1 connection we just close the connection and don't
even notice there is data there



On Mon, Aug 31, 2015 at 4:50 PM, Josh Matthews <jo...@joshmatthews.net>
wrote:

> _______________________________________________
> dev-tech-network mailing list
> dev-tech...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-network
>
>