Hello Adam, Ian,
Today I came across your draft "draft-ietf-websec-mime-sniff-03", and
noticed the point below :
2. If the octets were fetched via HTTP and there is an HTTP Content-
Type header field and the value of the last such header field has
octets that *exactly* match the octets contained in one of the
following lines:
+-------------------------------+--------------------------------+
| Bytes in Hexadecimal | Textual Representation |
+-------------------------------+--------------------------------+
| 74 65 78 74 2f 70 6c 61 69 6e | text/plain |
+-------------------------------+--------------------------------+
| 74 65 78 74 2f 70 6c 61 69 6e | text/plain; charset=ISO-8859-1 |
| 3b 20 63 68 61 72 73 65 74 3d | |
| 49 53 4f 2d 38 38 35 39 2d 31 | |
.../...
I was having a doubt about spaces being optional around the semi-colon,
so I just checked and indeed we have OWS before and after it :
http://www.ietf.org/id/draft-ietf-httpbis-p3-payload-18.txt
2.3. Media Types
HTTP uses Internet Media Types [RFC2046] in the Content-Type
(Section 6.8) and Accept (Section 6.1) header fields in order to
provide open and extensible data typing and type negotiation.
media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token
subtype = token
The type/subtype MAY be followed by parameters in the form of
attribute/value pairs.
parameter = attribute "=" value
attribute = token
value = word
Also, it is said here that quotes are allowed around the parameter
value :
A parameter value that matches the token production can be
transmitted as either a token or within a quoted-string. The quoted
and unquoted values are equivalent.
So examples below are completely valid :
Content-type: text/plain;charset="ISO-8859-1"
Content-type: text/plain ; charset=ISO-8859-1
Content-type: text/plain ;
charset="ISO-8859-1"
Thus the byte matching can only apply to the tokens and values. I think the
safest thing to do would be to refer to the HTTP spec to define the header
format then suggest byte matches for each fields, for instance :
If the octets were fetched via HTTP and there is an HTTP Content-
Type header field and the value of the last such header *exactly*
matches one of the media-types below, then the sniffed-type is
defined as the concatenation of the unquoted matching parts :
media-type = type "/" subtype *( OWS ";" OWS parameter )
sniffed-type = type "/" subtype 1*( "; " attribute "=" value )
All accepted media-types must *exactly* match :
- type = "text" (hex 74 65 78 74)
- subtype = "plain" (hex 70 6c 61 69 6e)
If a parameter is present, its attribute must be "charset"
(hex 63 68 61 72 73 65 74) and the value must be one of :
- "ISO-8859-1" (hex 49 53 4f 2d 38 38 35 39 2d 31)
- "iso-8859-1" (hex 69 73 6f 2d 38 38 35 39 2d 31)
- "UTF-8" (hex 55 54 46 2d 38)
Please also note that HTTP indicates that some attributes accept a
case-insensitive value. I have not yet found in the spec if "charset"
accepts a case-insensitive value, but given that you identified two
possible cases for "iso-8859-1", it is likely that "charset" falls into
this case.
Best regards,
Willy
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
