req_fsm: Always run vcl_synth upon client req reset

[dridi]

This way it becomes possible to log extra information for log consumers, call into VMODs, or whatever else one might want to do for a synthetic 408 response.

[bsdphk]

This feels too adhoc and "forced" Also: what about 400 ? If we want this, I think we need a new vcl_${bikeshed} which only have access to the session info (ie: IP#, proxy info) and they we should call it on all "short" responses in the C code.

[dridi]

This feels too adhoc and "forced"

Forced, for sure.

Since req_reset emulates a client side return (fail) and since such a return (fail) leads to vcl_synth, then in order to follow the state machine as documented, we should end up in vcl_synth.

Also: what about 400 ?

Is this ad-hoc core code handling or acting like a return (fail)?

If we want this, I think we need a new vcl_${bikeshed} which only have access to the session info (ie: IP#, proxy info) and they we should call it on all "short" responses in the C code.

I think we can have both.

The point that was raised on our end was that an emulated failure should be emulated all the way to vcl_synth to ensure VCL gets a final call to register pieces of information to be picked up by varnishncsa for the request being reset. This is about the existing request state machine converging towards either vcl_synth or vcl_deliver, not about a new session state machine.

[nigoroll]

I think we can have both.

if we added, say, a vcl_fail, we should call that and that only for the "fast error" paths.