HttpSM performs Http1.1 Logic

[a-canary]

The HttpSM and HttpTransact does a large amount of Http1.1 logic which increases complexity and convolutes Http2 and Http3 code paths and state machine states.

Solutions to this have been described in previous summits*, PR attempts** and projects***.

[PROPOSAL] HttpSM to interface with a ProxyTransaction (a base class for all protocols). Which requires Http1.1 logic to be refactored into a Http1Transaction, Http1ClientSession, and Http1ServerSession.

.* Http/2 to Origin Update
.** shinrich#1
.*** https://github.com/apache/trafficserver/projects/9

[a-canary]

@masaori335
This simplified diagram shows what I am working towards in my refactors. Ideally, HttpSM will only interface with ProxyTransaction, and know nothing of Http1/2/3 specific implementations.

[masaori335]

@a-canary Nice!

Ideally, HttpSM will only interface with ProxyTransaction, and know nothing of Http1/2/3 specific implementations.

Looks reasonable. Does this mean HTTP header parsing will be done on ProxyTransaction side ? I'm wondering about #5230 and this. It might be next step.

[a-canary]

I'll take a look at it. It sounds like the kind of thing we are trying to abstract out of HttpSM.

[maskit]

#6545 reminded me how H2 handle Cookie headers. We should probably keep Cookie headers separated if the connection for an origin is also H2.

[bryancall]

we have other issues tracking h2 to origin