Clarify behaviour for container managed HTTP headers

[markt-asf]

Taking Greg's text from #672 that adds support for early hints.

I understand that this method doesn't change the response headers, but we have other methods that will ultimately change the response headers, but we have not specified when, as it previously made little difference if they were set when called or when committed.

For example, if setLocale(Locale) has been called, would we expect to see a Content-Type header? Will content-length be sent if set by the application? probably Yes? Will content-length be set if the server can guess at it (e.g. some content aggregated in the buffer). Probably No?

We also have other container managed headers such as Date, Server and maybe X-Powered. Are these fields populated in the response prior to dispatch, and thus visible in response.getHeader() and would be sent with earlyHints, or are they set on commit?

Currently Jetty is modelling fields such as Date and Server as persistent fields. They are added to the response pre-dispatch, so they can be seen by the application. Their values can be changed if the application wishes, but they cannot be removed (as sending Date is MUST element in the RFC). So should these would be included in the 103 early hints? I don't see why not, but then I don't see any examples doing so.

I think we have been deliberately vague about server managed headers vs application managed headers. Maybe we need to be a bit less vague now? Or at least have language here that allows for the different possible implementations of server managed headers.

[gregw]

They key question I think we should answer, is how and when are server generated response fields visible to the application?

The Date header is a MUST send in RFC9110, so the server MUST send it (java has a clock). So should the application be able to see that header in the response? should the app be able to modify or delete that header? Jetty has it visible, allows it to be modified, but not deleted.

Jetty treats the Server header field the same way, but it is less important as the protocol is still correct without it.

The Content-Length and Content-Encoding header fields are typically set by the server when the response is committed. Should they be visible to the application after a flush or are they private to how the server actually sent the data. Jetty makes these visible to the app after a commit, but I don't see there is actually reason or need to do so. So perhaps we should say they may be visible.

Finally, there are partial field values derived from methods like setLocale and setCharacterEncoding. Should these be visible in the response headers immediately after these methods are called, or only after setContentType is called or the response is committed or never?

If we don't want definitive answers to any of these questions, then verbage saying result may differ would be good.

cheers