Re: I-D Action: draft-ietf-httpbis-incremental-02.txt

2025年10月27日(月) 18:14 Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>:
>
> I have attempted to implemented Incremental and have some questions:

Fantastic! Glenn, thank you very much for trying that out.

>
> The Incremental header with value ?1 indicates that the messages
> should not be buffered.  Draft Section 4.1 Permanent Rejection states:
>
>    When an intermediary rejects an incremental message -- either a
>    request or a response -- due to security concerns with regard to the
>    payload that the message might convey, the intermediary SHOULD
>    respond with a 501 (Not Implemented) error with an
>    incremental_refused Proxy-Status response header field (Section 5).
>
> RFC 9209 The Proxy-Status HTTP Response Header Field
> https://www.rfc-editor.org/rfc/rfc9209
> explicitly states in Section 2. The Proxy-Status HTTP Field:
>
>     Origin servers MUST NOT generate the Proxy-Status field.
>
> ? How should origin servers reject Incremental?  HTTP origin servers
> might be gateways to other protocols, such as CGI, FastCGI, SCGI, AJP13.
> How should the origin server respond if the origin server/gateway is not
> a reverse HTTP proxy?  Send HTTP status 501 but omit Proxy-Status?

This is an excellent question!

My answer would be that, in such a case, the HTTP server is acting as
an intermediary (gateway) and therefore can emit a Proxy-Status
header.

I acknowledge that RFC 9110 defines "origin server" as the server with
authority over the target URI. However, my reading is that RFC 9209
uses the term to refer to servers from which the response originates.
Under that usage, a CGI/FCGI/AJP gateway is not an origin, so the
"MUST NOT generate Proxy-Status" prohibition does not apply. This also
reconciles the CDN examples in RFC 9209, which show CDNs—despite being
authoritative servers (i.e., origin servers under RFC 9110)—generating
Proxy-Status.

>
> ? Related, for reverse HTTP proxy, if adding Proxy-Status but the server
> has not defined a name for itself (ExampleCDN), or does not wish to
> share its name, is there an acceptable token to use to indicate this?
>   e.g. Proxy-Status: unspecified;error=incremental_refused
> "unspecified"?  "anonymous"?  "private"?
> Should I use the same token as the HTTP 'Server' response header?

I'm not sure the value of the Server header is appropriate, as Section
2 of RFC 9209 states that "it might be a service name (but not a
software or hardware product name)". I think the hostname (or the
value of the authority) might be a good fit here.

>
>
> If Incremental is not a valid structured-field boolean, then it
> must be ignored.
>
>    Only Boolean values (Section 3.3.6
>    of [STRUCTURED-FIELDS]) are valid; a recipient ignores the field if
>    it contains any other type.
>
> ? Should the header still be forwarded?  A strict
> intermediary might choose to omit the header.  Is that permitted?
> How might doing so affect header signatures?  Should Incremental
> be excluded from header signatures?

I do not think there is a reason to drop Incremental when it is
considered broken. Incremental is an HTTP extension, and therefore,
there will always be intermediaries that do not recognize the
Incremental header. They will forward the header as-is anyways.

>
>
> ? Should Incremental be added with HTTP/1.1 Upgrade response header?
> (Or should the draft suggest to omit Incremental with Upgrade?)

I do not think so, as the 101 response does not have a body; framing
of HTTP/1.1 is terminated at the end of the HTTP header section.

>
>
> ? Should Incremental be ignored in *response* headers with status 1xx?
> (There is no response body with HTTP status 1xx.)
> Should the draft suggest omitting Incremental with HTTP status 1xx?

I'd say no, because not all the headers found in 1xx are meant to
refer to that response. The headers contained by an 103 response is an
expectation of what the final response might convey; it would be
perfectly fine to have an Incremental header in 103.

>
>
> Cheers, Glenn



-- 
Kazuho Oku

Received on Monday, 27 October 2025 11:21:58 UTC