Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 62446
Status: rejected
Priority: 0/
Queue: CGI

Owner: MARKSTOS [...]

Bug Information
Severity: (no value)
Broken in: 3.49
Fixed in: (no value)

Subject: LF only instead of CRLF breaks multiform POST data processing on file uploads from certain devices
Download (untitled) / with headers
text/plain 1.3k v. 3.49 fails to process multipart POST submissions that use LF instead of CRLF as line separators in POST data. This happens at least with some Android devices. This bug may, or may not, be related to the earlier reported problem in the bug submission 31107. A suggested bug fix consists of a few modified lines of code. With the suggested modifications, the problem disappears. The revised and the original are attached. Run diff to see the modified lines of code. A sample multipart POST file upload request from an Android device is attached as ''. Compare it with a multipart POST file upload request from a Windows client in '' Apparently, attempts to guess the line separators while processing form submissions. It appears however that guessing is done on the basis of machine architecture and not on the basis of the data in a POST submission. I believe the latter approach would make more sense since these days the client architecture is no longer a reliable indicator of whether the client machine uses CRLF or LF only. I tried contacting Lincoln Stein for a few months suggesting to incorporate this bug fix into new releases of I have got no response from him so far. Regardless of that, I believe posting the suggested fix here will help at least those who experience this bug. - Val
text/plain 1.2k
SERVER_SOFTWARE=lighttpd/1.4.26 SERVER_NAME=erased_for_privacy GATEWAY_INTERFACE=CGI/1.1 SERVER_PROTOCOL=HTTP/1.1 SERVER_PORT=80 SERVER_ADDR= REQUEST_METHOD=POST REDIRECT_STATUS=200 REQUEST_URI=/cgi-bin/upload.php REMOTE_ADDR=erased_for_privacy REMOTE_PORT=18172 CONTENT_LENGTH=516 SCRIPT_FILENAME=/opt/share/www/cgi-bin/upload.php SCRIPT_NAME=/cgi-bin/upload.php DOCUMENT_ROOT=/opt/share/www/ HTTP_USER_AGENT=Java0 HTTP_HOST=server_name_erased_for_privacy HTTP_CONNECTION=Keep-Alive HTTP_CONTENT_LENGTH=516 CONTENT_TYPE=multipart/form-data; boundary=================================== --================================== Content-Disposition: form-data; name="userfile"; filename="vkpw.db" Content-Type: application/octet-stream UPM!ÿR}(ўQõö [#0•Zѐ²–‚)f8…š–Öó"L¡ÙvÁm•€Å ˆg^Xæt‹1¥L,~¬û]RôXˆ!ÁË[ü5 DðyAΛ2o¥€ôß>Ê­`ªÃ¯ê6·r9Eø­h¢© G6æSÈIôÉ4æiœÕ¡#ÉÉJÔ]ÿF}#CâEFóxó©ãZåMõR5Þ#ð¼Þ ´©lÙcʃ8Ž¥ÄIÔ$ª?‹"2n¶u êlQ¤¬@º2žù;\óÄ÷é4%¥pbÃðíÝü°)a¹Áo¤1žèÄ0^Ô¬ž 1u°nñf\õ ®c ’‚VOåþG¦Î¬âï…×äMCîÚÈm»/}Ñ$IFi3g$¤C´¼gšõ•z÷;¯ÏÁ¯£òG¬„Ó <-ªì»=k/•½ --==================================--
text/plain 253.2k

Message body is not shown because it is too large.

text/plain 1.5k
卅剖䕒当但呗䅒䔽汩杨瑴灤⼱⸴⸲㘊卅剖䕒彎䅍䔽敲慳敤彦潲彰物癡捹䝁呅坁奟䥎呅剆䅃䔽䍇䤯ㄮㄊ卅剖䕒彐剏呏䍏䰽䡔呐⼱⸱卅剖䕒彐佒吽㠰卅剖䕒彁䑄刽〮〮〮《剅兕䕓呟䵅呈佄㵐体吊剅䑉剅䍔当呁呕匽㈰《剅兕䕓呟啒䤽⽣杩ⵢ楮⽵灬潡搮灨瀊剅䵏呅彁䑄刽敲慳敤彦潲彰物癡捹剅䵏呅彐佒吽㌹㠳䍏乔䕎呟䱅乇呈㴴㜸千剉偔彆䥌䕎䅍䔽⽯灴⽳桡牥⽷睷⽣杩ⵢ楮⽵灬潡搮灨瀊千剉偔彎䅍䔽⽣杩ⵢ楮⽵灬潡搮灨瀊䑏䍕䵅乔归住吽⽯灴⽳桡牥⽷睷⼊䡔呐录卅剟䅇䕎吽䩡歡牴愠䍯浭潮猭䡴瑰䍬楥湴⼳⸰䡔呐彈体吽敲慳敤彦潲彰物癡捹䡔呐彃低呅乔彌䕎䝔䠽㐷㠊䍏乔䕎呟呙偅㵭畬瑩灡牴⽦潲洭摡瑡㬠扯畮摡特㵷稱浍猶娵剡䈶捫㐰搴㡫䍖畔兎噦扄ⴊⴭ睺ㅭ䵳㙚㕒慂㙣欴つ㐸歃噵呑乖晢䐭䍯湴敮琭䑩獰潳楴楯渺⁦潲洭摡瑡㬠湡浥㴢畳敲晩汥∻⁦楬敮慭攽≶歰眮摢∊䍯湴敮琭呹灥㨠慰灬楣慴楯港潣瑥琭獴牥慭㬠捨慲獥琽䥓伭㠸㔹ⴱ䍯湴敮琭呲慮獦敲ⵅ湣潤楮机⁢楮慲礊啐䴂⇿剿紨톞퍏輜鎩醪ﶠ橇큺튭迷靌儍䉴忂�ᖞ⭞퉷襹쏦㡳혛뒘쎌懀⹩敢鈿셪勅乻�땚䈺数Ù䳼쮲삃藾푰㩦≰㶉貅⅘�抾㏝ᶈゥ덺뿤蘳ꋤ灝藌ꞃ䎝⎜묚ⴜꯝ邝커ꊒꘜ푗Ꝺ넋�埽말⟕㥇쪪 䪚蘌欌殈ᵿ䨋�ᬆ郣㹉T鼎숗褺輼엞��悳쉠ŧ큯ଊⴭ睺ㅭ䵳㙚㕒慂㙣欴つ㐸歃噵呑乖晢䐭ⴭ
text/plain 253.4k

Message body is not shown because it is too large.

Subject: Re: [ #62446] LF only instead of CRLF breaks multiform POST data processing on file uploads from certain devices
Date: Mon, 25 Oct 2010 15:40:36 -0400
To: bug-CGI [...]
From: Mark Stosberg <mark [...]>
Download (untitled) / with headers
text/plain 186b
Thanks for the report. There are other people helping maintain now, and we also get these bug reports and act on them as we have time. We'll look into your suggestion. Mark
RT-Send-CC: yanick-cpan [...]
Download (untitled) / with headers
text/plain 938b
Before going further with this I would like to be sure that the change we are making brings closer in line with RFCs, and is not just bloat to support other buggy software. Here's a couple related primary documents I've found so far: RFC 2387 - The MIME Multipart/Related Content-type This document refers to neither newlines nor CRLF. The CGI 1.1 RFC says a bit on the topic, including " the newline (NL) sequence is LF; servers SHOULD also accept CR LF as a newline." From my so far of the two documents above, it looks like we should support LF as well as CRLF. For an additional reference, here is the "diff" of 3.27 with the version before it: To move this ticket forward, I'd like a proposal that's backed by standards, not just how some user agents behave. Mark
Download (untitled) / with headers
text/plain 240b
This issue has been copied to: please take all future correspondence there. This ticket will remain open but please do not reply here. This ticket will be closed when the github issue is dealt with.
Download (untitled) / with headers
text/plain 126b
Rejecting - patch lacks automated tests and breaks existing automated tests. If you can fix both these i am happy to apply it.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to