Add CMake option ALLOW_NONEMPTY_204_RESPONSE
RFC2616 is very strict when it comes to "204 No Content" responses, requiring them to actually be empty. However, not everyone follows this (that is, they return content in 204 responses), causing otherwise valid HTTP responses to be rejected.
This PR adds a CMake option ALLOW_NONEMPTY_204_RESPONSE (which sets a preprocessor macro with the same name) that disables rejecting 204 responses with content, so that you can instead ignore the body of the response in those cases.
Even the updated RFC 9110 has the following:
A 204 response is terminated by the end of the header section; it cannot contain content or trailers.
Can you send examples of sites that are violating this?
Can you send examples of sites that are violating this?
This is in a context of OpenRTB bid responses, so it's not an actual website. The OpenRTB standard allows 204 responses to mean no bid.
We've been using Proxygen with this as a patch for several years, but I was hoping to get it in to the main branch to avoid needing to patch, and possibly to help others that may come across this issue.
At this point, we don't have any partners with this behavior anymore, but since it's quite a resource strain when it happens (the connection pools can't reuse the connection, so new connections need to be opened for every 204 response), it's something we want to keep.
Can you migrate to HTTP/2 so an individual request failure doesn’t preclude connection re-use?
From: Mats Attnäs @.> Reply-To: facebook/proxygen @.> Date: Tuesday, September 20, 2022 at 1:32 AM To: facebook/proxygen @.> Cc: Alan Frindell @.>, Comment @.***> Subject: Re: [facebook/proxygen] Add CMake option ALLOW_NONEMPTY_204_RESPONSE (PR #430)
Can you send examples of sites that are violating this? This is in a context of OpenRTB bid responses, so it's not an actual website. The OpenRTB standard allows 204 responses to mean no bid. We've been using Proxygen with this as a patch for ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd
Can you send examples of sites that are violating this?
This is in a context of OpenRTB bid responses, so it's not an actual website. The OpenRTB standard allows 204 responses to mean no bid.
We've been using Proxygen with this as a patch for several years, but I was hoping to get it in to the main branch to avoid needing to patch, and possibly to help others that may come across this issue.
At this point, we don't have any partners with this behavior anymore, but since it's quite a resource strain when it happens (the connection pools can't reuse the connection, so new connections need to be opened for every 204 response), it's something we want to keep.
— Reply to this email directly, view it on GitHubhttps://github.com/facebook/proxygen/pull/430#issuecomment-1252019565, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB7AQ2NJTWH4QDNGWBEBIBTV7FZBXANCNFSM6AAAAAAQQDJNKI. You are receiving this because you commented.Message ID: @.***>
From OpenRTB:
To express a “no-bid”, the options are to return an empty response with HTTP 204. Alternately if the bidder wishes to convey to the exchange a reason for not bidding, just a BidResponse object is returned with a reason code in the nbr attribute.
This is vague at best or more likely a violation of the HTTP spec. Do they mean return a 200 with a BidResponse object and a reason code?
From: Mats Attnäs @.> Reply-To: facebook/proxygen @.> Date: Tuesday, September 20, 2022 at 1:32 AM To: facebook/proxygen @.> Cc: Alan Frindell @.>, Comment @.***> Subject: Re: [facebook/proxygen] Add CMake option ALLOW_NONEMPTY_204_RESPONSE (PR #430)
Can you send examples of sites that are violating this? This is in a context of OpenRTB bid responses, so it's not an actual website. The OpenRTB standard allows 204 responses to mean no bid. We've been using Proxygen with this as a patch for ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd
Can you send examples of sites that are violating this?
This is in a context of OpenRTB bid responses, so it's not an actual website. The OpenRTB standard allows 204 responses to mean no bid.
We've been using Proxygen with this as a patch for several years, but I was hoping to get it in to the main branch to avoid needing to patch, and possibly to help others that may come across this issue.
At this point, we don't have any partners with this behavior anymore, but since it's quite a resource strain when it happens (the connection pools can't reuse the connection, so new connections need to be opened for every 204 response), it's something we want to keep.
— Reply to this email directly, view it on GitHubhttps://github.com/facebook/proxygen/pull/430#issuecomment-1252019565, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB7AQ2NJTWH4QDNGWBEBIBTV7FZBXANCNFSM6AAAAAAQQDJNKI. You are receiving this because you commented.Message ID: @.***>
I'm disinclined to merge this since it's validating misuse of HTTP.