DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28685>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28685 HttpParser.parseHeaders() throws an exception when parsing a malformed header line. Summary: HttpParser.parseHeaders() throws an exception when parsing a malformed header line. Product: Commons Version: 2.0 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I stumbled on a website which sends a malformed header line, which is not written as name:value. 0x0030 4854 5450 2f31 2e31 2033 3032 HTTP/1.1.302 0x0040 204f 626a 6563 7420 4d6f 7665 640d 0a53 .Object.Moved..S 0x0050 6572 7665 723a 204d 6963 726f 736f 6674 erver:.Microsoft 0x0060 2d49 4953 2f35 2e30 0d0a 4461 7465 3a20 -IIS/5.0..Date:. 0x0070 5475 652c 2032 3720 4170 7220 3230 3034 Tue,.27.Apr.2004 0x0080 2031 323a 3533 3a31 3420 474d 540d 0a50 .12:53:14.GMT..P 0x0090 3350 3a20 706f 6c69 6379 7265 663d 222f 3P:.policyref="/ 0x00a0 7733 632f 7033 702e 786d 6c22 2c20 4350 w3c/p3p.xml",.CP 0x00b0 3d22 4341 4f20 4453 5020 494e 4420 434f ="CAO.DSP.IND.CO 0x00c0 5220 4144 4d20 434f 4e6f 2043 5552 2043 R.ADM.CONo.CUR.C 0x00d0 5553 6920 4445 5620 5053 4120 5053 4420 USi.DEV.PSA.PSD. 0x00e0 4445 4c69 204f 5552 2043 4f4d 204e 4156 DELi.OUR.COM.NAV 0x00f0 2050 4859 204f 4e4c 2050 5552 2055 4e49 .PHY.ONL.PUR.UNI 0x0100 220d 0a43 6f6e 6e65 6374 696f 6e3a 2063 "..Connection:.c 0x0110 6c6f 7365 0d0a 4c6f 6361 7469 6f6e 3a20 lose..Location:. 0x0120 ---- ---- ---- ---- ---- ---- ---- ---- http://www.xxxxx 0x0130 ---- ---- ---- ---- ---- ---- ---- ---- xx.xx/xxx/agent. 0x0140 646c 6c3f 2626 746f 7672 3d32 3030 3131 dll?&&tovr=20011 0x0150 3031 3630 3026 7073 3375 3d26 7465 6d70 01600&ps3u=&temp (...) same long line continues : 0x02a0 6672 723d 2d32 3332 3435 2674 6573 745f frr=-23245&test_ 0x02b0 6465 703d 4245 520a 2674 7069 643d 360d dep=BER.&tpid=6. ---------------------------------------------------------------|=======| Here, the '&tpid=6' is taken as a message-header line. As is stated for both the HTTP/1.0 at '4.2 Message Headers' and HTTP/1.1 at '4.1 Message Types', a CRLF must separate each message header. As the HttpParser.readLine take LF as a line terminator, it splits the string "dep=BER\n&tpid=6". I don't think LF is allowed in a message header, so I modified parseHeader() to not throw an exception and simply skip the fragment and continue to the next (sending a WARN message should be better though). What should be the best policy ? Drop the splitted part or keep it merged with the previous line ? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
