I found some behaviour of zc.resourcelib which I'm not sure is intended that way: The lib takes care to apply only to HTML and XML content, so it tests whether the content type (if set) is among text/html and text/xml: if content_type == 'text/html' or content_type == 'text/xml': ... However, it does so by exact comparison, so it would apply to "text/html" but not "text/html; charset=utf-8". Wouldn't a check like if content_type.split(';', 1)[0] in ('text/html', 'text/xml'): ... be more appropriate? -- Thomas
Thomas Lotze wrote:
Wouldn't a check like
if content_type.split(';', 1)[0] in ('text/html', 'text/xml'): ...
be more appropriate?
Probably. Remember, zc.resourcelibrary's HTML injection code is a hack -- a necessary hack, but a hack none the less. I can say that because I did it. ;) Feel free to make the change you outlined, especially if this is causing you to get incorrect results in one of your apps. Also, does case matter here? Perhaps a .lower() should be added as well. -- Benji York Senior Software Engineer Zope Corporation
On Dec 4, 2007 9:15 AM, Benji York <benji@zope.com> wrote:
Also, does case matter here? Perhaps a .lower() should be added as well.
The major/minor type and the parameter names should be treated as case insensitive. There's a content-type parser in zope.publisher.contentype that should handle normalization properly, though something simpler is probably reasonable here if the major/minor type is all that's interesting. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Benji York wrote:
Feel free to make the change you outlined, especially if this is causing you to get incorrect results in one of your apps.
I've released 0.8 now, having made the change including case and whitespace normalization as well as tests for the behaviour. It's only at download.zope.org/distribution right now since I don't have the privileges to upload the package to PyPI. While writing the tests I noticed that the publisher doesn't cope with whitespace and funny case on the major type, though. -- Thomas
On Dec 4, 2007 5:43 PM, Thomas Lotze <thomas@thomas-lotze.de> wrote:
While writing the tests I noticed that the publisher doesn't cope with whitespace and funny case on the major type, though.
I don't recall if whitespace is allowed around the "/" in the type; it might not be. The code should probably allow it on input. Feel free to make the required changes to zope.publisher.contenttype. ;-) -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
I don't recall if whitespace is allowed around the "/" in the type; it might not be. The code should probably allow it on input.
It wasn't even about whitespace around the / but leading whitespace in front of the major type.
Feel free to make the required changes to zope.publisher.contenttype. ;-)
I'll first try to get my hands on some standards document on the subject, I guess. -- Thomas
On Dec 4, 2007 5:55 PM, Thomas Lotze <thomas@thomas-lotze.de> wrote:
It wasn't even about whitespace around the / but leading whitespace in front of the major type.
Wow. It probably didn't occur to me that would be screwed up.
I'll first try to get my hands on some standards document on the subject, I guess.
Some RFC on MIME headers. Don't recall which one offhand. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
On Dec 4, 2007 5:55 PM, Thomas Lotze <thomas@thomas-lotze.de> wrote:
It wasn't even about whitespace around the / but leading whitespace in front of the major type.
Wow. It probably didn't occur to me that would be screwed up.
I've now looked up RfC 2045 which states that there is to be no whitespace within the MIME type specification, i.e. in particular none around the slash. This requires a change to zope.publisher.contenttype. OTOH it's probably up to us how to treat whitespace surrounding the string specifying MIME type: - Either we decide that such a string should always follow the RfC exactly and contain no whitespace at all (which makes the way zope.publisher.http handles it the correct way), - or we allow for it to be some possibly whitespace-padded string that contains a valid MIME spec, which would allow for surrounding whitespace, but not space around the slash. I'd prefer the first option for clarity. Is there any reason to be forgiving regarding whitespace in the first place? As for capitalization, the RfC states clearly that major type, minor type and parameter names are case-insensitive. This requires a change to zope.publisher.http which currently says: if not content_type.startswith('text/'): raise ValueError(...) I'll do all that once we have agreed on one way of treating the MIME type specs. -- Thomas
Am Mittwoch, den 05.12.2007, 10:20 +0100 schrieb Thomas Lotze:
Fred Drake wrote:
On Dec 4, 2007 5:55 PM, Thomas Lotze <thomas@thomas-lotze.de> wrote:
It wasn't even about whitespace around the / but leading whitespace in front of the major type.
Wow. It probably didn't occur to me that would be screwed up.
I've now looked up RfC 2045 which states that there is to be no whitespace within the MIME type specification, i.e. in particular none around the slash. This requires a change to zope.publisher.contenttype. OTOH it's probably up to us how to treat whitespace surrounding the string specifying MIME type:
- Either we decide that such a string should always follow the RfC exactly and contain no whitespace at all (which makes the way zope.publisher.http handles it the correct way),
- or we allow for it to be some possibly whitespace-padded string that contains a valid MIME spec, which would allow for surrounding whitespace, but not space around the slash.
I'd prefer the first option for clarity. Is there any reason to be forgiving regarding whitespace in the first place?
That depends on the container format and therefore it's the responsibility of the container (e.g. a HTTP header) to remove the whitespace. Note that AFAICT RFC 2045 section 5.1 (that's what you're referring to AFAICT) defines the MIME type specification as done with the Content-Type header for MIME messages without defining exactly how the actual type relates to the container. IMHO we should not pay attention to whitespace. Christian -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
Christian Theune wrote:
That depends on the container format and therefore it's the responsibility of the container (e.g. a HTTP header) to remove the whitespace.
Note that AFAICT RFC 2045 section 5.1 (that's what you're referring to AFAICT) defines the MIME type specification as done with the Content-Type header for MIME messages without defining exactly how the actual type relates to the container.
That's why I asked about the intended semantics of our MIME type strings: should anything that's called a MIME or content type be strict according to the spec, it being the responsibility of whatever creates those strings to make them so, or should we have to be forgiving in all the places that consume MIME types?
IMHO we should not pay attention to whitespace.
I'm not sure whether you mean we should ignore whitespace in a MIME type string or not have to pay attention to the issue when consuming one. -- Thomas
Am Mittwoch, den 05.12.2007, 11:22 +0100 schrieb Thomas Lotze:
Christian Theune wrote:
That depends on the container format and therefore it's the responsibility of the container (e.g. a HTTP header) to remove the whitespace.
Note that AFAICT RFC 2045 section 5.1 (that's what you're referring to AFAICT) defines the MIME type specification as done with the Content-Type header for MIME messages without defining exactly how the actual type relates to the container.
That's why I asked about the intended semantics of our MIME type strings: should anything that's called a MIME or content type be strict according to the spec, it being the responsibility of whatever creates those strings to make them so, or should we have to be forgiving in all the places that consume MIME types?
IMHO we should not pay attention to whitespace.
I'm not sure whether you mean we should ignore whitespace in a MIME type string or not have to pay attention to the issue when consuming one.
IMHO we should assume whatever is given to us was unpacked by the container format and is intended to be a valid MIME type. Meaning we should not strip it. Christian -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
Christian Theune wrote:
IMHO we should assume whatever is given to us was unpacked by the container format and is intended to be a valid MIME type. Meaning we should not strip it.
OK, then we agree. Good that I did zc.resourcelibrary 0.8, not 1.0 yesterday ;o) -- Thomas
participants (4)
-
Benji York -
Christian Theune -
Fred Drake -
Thomas Lotze