multipart: allow MIME head to span read boundary#2392
Conversation
There was a problem hiding this comment.
Thank you for the patch, I agree we should merge this and backport it.
5cbdfc5 to
e72bebb
Compare
|
I’m fixing code — I missed a few things. |
da2963b to
1e30d0f
Compare
|
The body is truncated only when the body cannot be fully read: rack/lib/rack/multipart/parser.rb Lines 481 to 482 in 1e30d0f When multiple multipart parts are attached, the buffer may be refilled several times to read each part’s header. Please see the linked diff for details. |
|
@jeremyevans I’ve fixed the issue I noticed and force-pushed the changes 🙏 |
|
@ioquatix |
|
I saw that changelog were being pointed out in other PR reviews, so I added one as well. |
|
I will try to get this backported and released this weekend. |
Previously, the header size check compared `MIME_HEADER_BYTESIZE_LIMIT` against `@sbuf.string.bytesize`, which included previously read data. When the scan buffer held several megabytes of processed data plus a unprocessed header fragment, this could incorrectly raise “multipart mime part header too large.” Fix: compare the limit against `@sbuf.rest.bytesize` instead. This measures only the unread portion of the buffer—the region that may still contain the MIME header—ensuring the check applies to header data alone without being affected by prior reads. Co-authored-by: Shinichi Maeshima <netwillnet@gmail.com> Co-authored-by: krororo <krororo.07@gmail.com>
e2b471f to
89fe65f
Compare
Previously, the header size check compared `MIME_HEADER_BYTESIZE_LIMIT` against `@sbuf.string.bytesize`, which included previously read data. When the scan buffer held several megabytes of processed data plus a unprocessed header fragment, this could incorrectly raise “multipart mime part header too large.” Fix: compare the limit against `@sbuf.rest.bytesize` instead. This measures only the unread portion of the buffer—the region that may still contain the MIME header—ensuring the check applies to header data alone without being affected by prior reads. Co-authored-by: Shinichi Maeshima <netwillnet@gmail.com> Co-authored-by: krororo <krororo.07@gmail.com>
Previously, the header size check compared `MIME_HEADER_BYTESIZE_LIMIT` against `@sbuf.string.bytesize`, which included previously read data. When the scan buffer held several megabytes of processed data plus a unprocessed header fragment, this could incorrectly raise “multipart mime part header too large.” Fix: compare the limit against `@sbuf.rest.bytesize` instead. This measures only the unread portion of the buffer—the region that may still contain the MIME header—ensuring the check applies to header data alone without being affected by prior reads. Co-authored-by: Shinichi Maeshima <netwillnet@gmail.com> Co-authored-by: krororo <krororo.07@gmail.com>
Previously, the header size check compared `MIME_HEADER_BYTESIZE_LIMIT` against `@sbuf.string.bytesize`, which included previously read data. When the scan buffer held several megabytes of processed data plus a unprocessed header fragment, this could incorrectly raise “multipart mime part header too large.” Fix: compare the limit against `@sbuf.rest.bytesize` instead. This measures only the unread portion of the buffer—the region that may still contain the MIME header—ensuring the check applies to header data alone without being affected by prior reads. Co-authored-by: Shinichi Maeshima <netwillnet@gmail.com> Co-authored-by: krororo <krororo.07@gmail.com>
Previously, the header size check compared `MIME_HEADER_BYTESIZE_LIMIT` against `@sbuf.string.bytesize`, which included previously read data. When the scan buffer held several megabytes of processed data plus a unprocessed header fragment, this could incorrectly raise “multipart mime part header too large.” Fix: compare the limit against `@sbuf.rest.bytesize` instead. This measures only the unread portion of the buffer—the region that may still contain the MIME header—ensuring the check applies to header data alone without being affected by prior reads. Co-authored-by: Shinichi Maeshima <netwillnet@gmail.com> Co-authored-by: krororo <krororo.07@gmail.com>
|
Okay, all 3 releases are done. |
|
Does |
No, because that is only done in the initial read, there shouldn't be any data already in the buffer when we start looking for the boundary. |
Previously, the header size check compared
MIME_HEADER_BYTESIZE_LIMITagainst@sbuf.string.bytesize, whichincluded previously read data. When the scan buffer held several megabytes of processed data plus a unprocessed
header fragment, this could incorrectly raise “multipart mime part header too large.”
Fix: compare the limit against
@sbuf.rest.bytesizeinstead. This measures only the unread portion of thebuffer—the region that may still contain the MIME header—ensuring the check applies to header data alone
without being affected by prior reads.