hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject Re: [PATCH] Multiple transfer encodings are still not handled properly
Date Thu, 10 Jul 2003 14:15:54 GMT
14.41 Transfer-Encoding

     Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding

2.1 Augmented BNF
      A construct "#" is defined, similar to "*", for defining lists of
      elements. The full form is "<n>#<m>element" indicating at least
      <n> and at most <m> elements, each separated by one or more commas
      (",") and OPTIONAL linear white space (LWS). This makes the usual
      form of lists very easy; a rule such as
         ( *LWS element *( *LWS "," *LWS element ))
      can be shown as
      Wherever this construct is used, null elements are allowed, but do
      not contribute to the count of elements present. That is,
      "(element), , (element) " is permitted, but counts as only two
      elements. Therefore, where at least one element is required, at
      least one non-null element MUST be present. Default values are 0
      and infinity so that "#element" allows any number, including zero;
      "1#element" requires at least one; and "1#2element" allows one or


-----Original Message-----
From:	Michael Becke [mailto:becke@u.washington.edu]
Sent:	Thu 7/10/2003 15:51
To:	Commons HttpClient Project
Subject:	Re: [PATCH] Multiple transfer encodings are still not handled properly
Which section of the RFC talks about this?

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message