dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dotgnu-pnet] [bug #26179] ChunkedDecoderStream.ReadChunkSize fails to p


From: Thomas Uxiou
Subject: [Dotgnu-pnet] [bug #26179] ChunkedDecoderStream.ReadChunkSize fails to parse "123 <SPACE> <CR> <LF>"
Date: Tue, 14 Apr 2009 13:39:52 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en; rv:1.9.0.8) Gecko/20080528 Epiphany/2.22 Firefox/3.0

URL:
  <http://savannah.gnu.org/bugs/?26179>

                 Summary: ChunkedDecoderStream.ReadChunkSize fails to parse
"123 <SPACE> <CR> <LF>"
                 Project: DotGNU Portable.NET
            Submitted by: uxiou
            Submitted on: Tue Apr 14 13:39:51 2009
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I'm not sure if "123 <SP> <CR><LF>" is legal but "123 <SP> ;a=1 <CR><LF>" is
(see below).

sample HTTP stream:
http://co.za/cgi-bin/whois.sh?Domain=example.co.za

fix:
# diff -ur pnetlibORG/System/Net/HttpWebResponse.cs
pnetlib/System/Net/HttpWebResponse.cs
# --- pnetlibORG/System/Net/HttpWebResponse.cs  2009-04-14 13:39:43.000000000
+0200
# +++ pnetlib/System/Net/HttpWebResponse.cs     2009-04-14 15:32:05.000000000
+0200
# @@ -425,7 +425,7 @@
#                               {
#                                       throw new IOException("unexpected end 
of stream");
#                               }
# -                             if(b == 59) // chunk extension, we don't care
# +                             if(b == 59 || b == 32 || b == 9) // chunk 
extension, we don't care
#                               {
#                                       append = false;
#                               }



RFC 2068

# 2.1 Augmented BNF
#
# The grammar described by this specification is word-based. Except
# where noted otherwise, linear whitespace (LWS) can be included
# between any two adjacent words (token or quoted-string), and
# between adjacent tokens and delimiters (tspecials), without
# changing the interpretation of a field. 

# 3.6 Transfer Codings
#
# chunk          = chunk-size [ chunk-ext ] CRLF
# hex-no-zero    = <HEX excluding "0">
# chunk-size     = hex-no-zero *HEX
# chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
# tspecials      = "(" | ")" | "<" | ">" | "@"
#                         | "," | ";" | ":" | "\" | <">
#                         | "/" | "[" | "]" | "?" | "="
#                         | "{" | "}" | SP | HT
# LWS            = [CRLF] 1*( SP | HT )

# 2.2 Basic Rules
# HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
# protocol elements except the entity-body (see appendix 19.3 for
# tolerant applications).







    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26179>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]