There was a bit of a discussion about the relationship between SPDY/H2
and the synthesized HTTP/1.x requests on the chat the other day with
respect to getting access to logging connection-oriented data from the
synthesized request.
I'm working through similar issues with TS-3578 with respect to session
hooks, SPDY/H2 and synthesized HTTP/1.x requests. I'm copying a comment
I made on that bug here to spark discussion. I have my opinion, but I'd
like to understand the communities expectations for SSN hooks.
The rearrangement in TS-3578 has worked well for my needs with the
tcpinfo plugin. For SSN_CLOSE, the hook gets triggered for both the
HttpClientSession and the SpdyClientSession or Http2ClientSession. We
only log for the Spdy/Http2 Client session since that is the only
session with access to the netvc.
For SSN_START, the hook is only called on the HttpClientSession, so no
logging is performed in the Http2/Spdy case since the HttpClientSession
does not have access to the netvc.
This brings up a broader issue of when should the session start and
session close hooks be called in the Http2/Spdy case.
* Only on the Http2/Spdy client sessions
* On both the Http2/Spdy and HttpClientSessions. In the case of the
HttpClientSession, this would be with the same frequency as the
TXN_START and TXN_CLOSE hooks.
* Only on the HttpClientSession. In this case we would need to
figure out how to get access to the netvc from the PluginVC. Plus the
SSN hooks would not correspond to the real start and end of the user
agent network connection.
At this point, I prefer the option of calling the SSN hooks only on the
Http2/Spdy client sessions. But I need feedback. Do people rely on SSN
hooks having access to transaction data?
Of course in the case of a native HTTP/1.x connection, nothing should
change. The SSN and TXN hooks will be invoked against the
HttpClientSession.
Thanks,
Susan
