moonchen commented on code in PR #13333:
URL: https://github.com/apache/trafficserver/pull/13333#discussion_r3475851076
##########
plugins/authproxy/authproxy.cc:
##########
@@ -296,6 +296,16 @@ AuthWriteHeadRequest(AuthRequestContext *auth)
// Next, we need to rewrite the client request URL to be a HEAD request.
TSReleaseAssert(TSHttpHdrMethodSet(rq.buffer, rq.header,
TS_HTTP_METHOD_HEAD, -1) == TS_SUCCESS);
+ // This sub-request is bodyless (HEAD + Content-Length: 0), but the copied
+ // client request may carry request-body framing (e.g. a chunked POST or
+ // Expect: 100-continue). Left in place it is self-contradictory: ATS sets up
+ // a request-body tunnel for a body that never arrives (stalling the probe
+ // until timeout), and proxy.config.http.reject_head_with_content rejects a
+ // HEAD that declares content. Strip the framing when forcing
Content-Length: 0.
+ HttpRemoveMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_TRANSFER_ENCODING);
+ HttpRemoveMimeHeader(rq.buffer, rq.header, "Trailer");
+ HttpRemoveMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_EXPECT);
+
HttpSetMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_CONTENT_LENGTH, 0u);
Review Comment:
ATS core already guarantees at most one `Content-Length` field here. During
request parsing, `validate_hdr_content_length()` (`src/proxy/hdrs/HTTP.cc`)
enforces RFC 7230 §3.3.3: a request with differing duplicate `Content-Length`
values is rejected with 400 (so it never reaches the plugin), same-value
duplicates are collapsed to a single field, and all `Content-Length` is dropped
when `Transfer-Encoding` is present. authproxy copies the request at
`POST_REMAP`, after parsing — so there are no duplicate `Content-Length` fields
to leave behind, and the single `Set` to 0 is sufficient.
`Transfer-Encoding`/`Trailer`/`Expect` get the looping remove instead
because they can survive parsing (and TE is not deduplicated), so they need
explicit stripping.
##########
plugins/authproxy/authproxy.cc:
##########
@@ -333,6 +343,13 @@ AuthWriteRangeRequest(AuthRequestContext *auth)
TSReleaseAssert(TSHttpHdrMethodSet(rq.buffer, rq.header,
TS_HTTP_METHOD_GET, -1) == TS_SUCCESS);
}
+ // The body is dropped (Content-Length: 0), so strip any request-body framing
+ // (Transfer-Encoding/Trailer/Expect) copied from the client request to keep
+ // the sub-request well-formed.
+ HttpRemoveMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_TRANSFER_ENCODING);
+ HttpRemoveMimeHeader(rq.buffer, rq.header, "Trailer");
+ HttpRemoveMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_EXPECT);
+
HttpSetMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_CONTENT_LENGTH, 0u);
Review Comment:
Same as the comment on the HEAD transform: duplicate `Content-Length` can't
reach this point. `validate_hdr_content_length()` (RFC 7230 §3.3.3) rejects or
collapses duplicates during request parsing, before authproxy's `POST_REMAP`
hook, so the request carries at most one `Content-Length` and the single `Set`
to 0 is sufficient.
##########
plugins/authproxy/authproxy.cc:
##########
@@ -386,6 +403,14 @@ AuthWriteRedirectedRequest(AuthRequestContext *auth)
TSHandleMLocRelease(rq.buffer, rq.header, murl);
HttpSetMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_HOST, hostbuf);
+
+ // The body is dropped (Content-Length: 0), so strip any request-body framing
+ // (Transfer-Encoding/Trailer/Expect) copied from the client request to keep
+ // the sub-request well-formed.
+ HttpRemoveMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_TRANSFER_ENCODING);
+ HttpRemoveMimeHeader(rq.buffer, rq.header, "Trailer");
+ HttpRemoveMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_EXPECT);
+
HttpSetMimeHeader(rq.buffer, rq.header, TS_MIME_FIELD_CONTENT_LENGTH, 0u);
Review Comment:
Same as the comment on the HEAD transform: duplicate `Content-Length` can't
reach this point. `validate_hdr_content_length()` (RFC 7230 §3.3.3) rejects or
collapses duplicates during request parsing, before authproxy's `POST_REMAP`
hook, so the request carries at most one `Content-Length` and the single `Set`
to 0 is sufficient.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
