)]}'
{
  "commit": "fca3e98e93b54719a88d5bc91693b918c597bc55",
  "tree": "b572452a9f02c6e4c80cbaa04cdee69942be8226",
  "parents": [
    "817e8ca43ba600b8d633b8e7870e1ac7d69c6fca"
  ],
  "author": {
    "name": "reubent",
    "email": "reubent@google.com",
    "time": "Thu Jul 16 12:58:22 2026 -0700"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Thu Jul 16 12:58:59 2026 -0700"
  },
  "message": "Allow responses to HEAD requests to contain Content-Length or Transfer-Encoding\n\nThe failing prober sends curl requests with the [`-I` param](http://cs///depot/google3/net/fabric/monitoring/cloud_sdn_management/cep_workflows/csdnm_efg_probers/efg_control_plane_shard0_prober/efg_control_plane_shard0_prober.pb.txt;ws\u003dreubent%2F418520;l\u003d63), meaning it is sending a `HEAD` request.\n\nEnforcement of `content_length_or_transfer_encoding_in_bodyless_response` was initially added to the same block where we check if the response should have a body or not. Responses to HEAD requests should not have a body. The logic error there is that, even though a response to a HEAD request cannot have a body, it is still permitted by the RFCs to return headers that describe the body it _would have_. RFC 9110, Section 9.3.2: \"The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET\".\n\nSo this check has been moved to been moved to BalsaFrame::ProcessHeader and only limits TE/CL on 1xx and 204. New e2e and unit tests are added to confirm all RFC defined behavior:\n\n\u003e A server MAY send a Content-Length header field in a response to a HEAD request (Section 9.3.2);\n\n`HEADResponseWithContentLengthAllowed`\n\n\u003e A server MAY send a Content-Length header field in a 304 (Not Modified) response\n\n`304WithContentLengthAllowed`\n\n\u003e A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content)\n\n`1xxResponseWithContentLengthDisallowed and 204ResponseWithContentLengthDisallowed`\n\n\u003e Transfer-Encoding MAY be sent in a response to a HEAD request or in a 304 (Not Modified) response (Section 15.4.5 of [HTTP]) to a GET request, neither of which includes a message body\n\n`304WithTransferEncodingAllowed` and `HEADResponseWithTransferEncodingAllowed`\n\n\u003e A server MUST NOT send a Transfer-Encoding header field in any response with a status code of 1xx (Informational) or 204 (No Content).\n\n`204WithTransferEncodingDisallowed`\n\nProtected by gfe2_reloadable_flag_use_zoll_balsa_http_validation_policy.\n\nPiperOrigin-RevId: 949125790\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e5abcf84384649d3187daafbe4b0020489ef8208",
      "old_mode": 33188,
      "old_path": "quiche/balsa/balsa_frame.cc",
      "new_id": "60a3e366504b014d0ac34602e17d0a68830544af",
      "new_mode": 33188,
      "new_path": "quiche/balsa/balsa_frame.cc"
    }
  ]
}