hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28685] New: - HttpParser.parseHeaders() throws an exception when parsing a malformed header line.
Date Thu, 29 Apr 2004 13:18:58 GMT
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: commons-httpclient-dev@jakarta.apache.org
        ReportedBy: boisa@libertysurf.fr


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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message