Skip Menu |

This queue is for tickets about the HTTP-MultiPartParser CPAN distribution.

Report information
The Basics
Id: 120473
Status: rejected
Priority: 0/
Queue: HTTP-MultiPartParser
People
Owner: Nobody in particular
Requestors: andy [...] camavision.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Wed Mar 01 11:57:08 2017 andy [...] camavision.com - Ticket created
Subject: End boundary strictness
Date: Wed, 1 Mar 2017 09:24:01 -0600
To: <bug-HTTP-MultiPartParser [...] rt.cpan.org>
From: andy <andy [...] camavision.com>
I have an old client, in the wild, that uploads data, but does not include the final CRLF after the closing --. This patch makes the parser a little less strict, it'll consume the CRLF if its there, but doesnt require it. I tested it a little bit and it seems to work for both: --BOUND content --BOUND--CRLF --BOUND content --BOUND-- Would it be possible to apply this? Thanks for your time, -Andy

Message body is not shown because sender requested not to inline it.

  Sat Mar 04 10:53:07 2017 chansen [...] cpan.org - Correspondence added
Hi Andy, Vid Ons, 01 Mar 2017 kl. 11.57.08, skrev andy@camavision.com: Show quoted text
> I have an old client, in the wild, that uploads data, but does not > include the final CRLF after the closing --.
Unfortunately I can’t accept this patch as it breaks the self-delimiting nature of a multipart messagebody, wherein the "end" of the message-body is indicated by the ending multipart boundary. This required by RFC 2616 <https://tools.ietf.org/html/rfc2616#section-3.7.2> and <https://tools.ietf.org/html/rfc7231#section-3.1.1.4>: The message body is itself a protocol element; a sender MUST generate only CRLF to represent line breaks between body parts. Regards -- chansen
  Sat Mar 04 10:53:07 2017 The RT System itself - Status changed from 'new' to 'open'
  Mon Apr 10 03:03:44 2017 chansen [...] cpan.org - Status changed from 'open' to 'rejected'