fix(http): send minimal end multipart boundary #6661
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
See: https://datatracker.ietf.org/doc/html/rfc2046#section-5.1.1 RFC 2046, §5.1.1, says that a multipart body ends with a single, optional CRLF sequence, and that extra data (the epilogue) is _allowed_, but should be _ignored_ by receiving agents: ``` multipart-body := [preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue] close-delimiter := delimiter "--" transport-padding := *LWSP-char ; Composers MUST NOT generate ; non-zero length transport ; padding, but receivers MUST ; be able to handle padding ; added by message transports. epilogue := discard-text discard-text := *(*text CRLF) *text ; May be ignored or discarded. ``` Note that the end is signaled by `close-delimiter`, followed by `transport-padding` and an optional CRLF and epilogue. Now, in theory we need not send even the first CRLF (although most clients and servers expect it, so we have to keep it), but the second CRLF sequence is more than extraneous. However, that second CRLF becomes problematic with some middleware. For example, the Azure Web Application Firewall has strict rules when it comes to the epilogue section and will block requests if it detects anything there. This is not standards-compliant, but given that we don't have to send two CRLF terminators anyway, we can continue being standards-compliant while allowing our users to access WAF-protected websites.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've bumped into an issue where Azure's Web Application Firewall (an L7 firewall) was blocking multipart/form-data requests sent by Axios with the message: "Multipart request body failed strict validation". There wasn't much info otherwise, so debugging this took me a while.
It turned out that the problem is an extra CRLF sequence that Axios adds at the end of the request body, which is allowed by the standard, but disallowed by Azure. This commit removes that extra final CRLF, which renders Axios interoperable with Azure's strict WAF policies, while keeping the code standards-compliant.
What follows below is the technical explanation, taken from the commit itself.
See: https://datatracker.ietf.org/doc/html/rfc2046#section-5.1.1
RFC 2046, §5.1.1, says that a multipart body ends with a single, optional CRLF sequence, and that extra data (the epilogue) is allowed, but should be ignored by receiving agents:
Note that the end is signaled by
close-delimiter, followed bytransport-paddingand an optional CRLF and epilogue.Now, in theory we need not send even the first CRLF (although most clients and servers expect it, so we have to keep it), but the second CRLF sequence is more than extraneous.
However, that second CRLF becomes problematic with some middleware. For example, the Azure Web Application Firewall has strict rules when it comes to the epilogue section and will block requests if it detects anything there. This is not standards-compliant, but given that we don't have to send two CRLF terminators anyway, we can continue being standards-compliant while allowing our users to access WAF-protected websites.