- From: <David.Carson@nokia.com>
- Date: Wed, 3 May 2006 17:46:19 -0400
- To: <derhoermi@gmx.net>
- Cc: <public-webapi@w3.org>
Wow! I am very impressed with the number of responses and comments I have received from my post. Bjoern, et al, you are correct, content-type is not mandatory. Mark Nottingham pointed out: --------- RFC2616, Section 7.2.1; > Any HTTP/1.1 message containing an entity-body SHOULD include a > Content-Type header field defining the media type of that body. If > and only if the media type is not given by a Content-Type field, > the > recipient MAY attempt to guess the media type via inspection of its > content and/or the name extension(s) of the URI used to identify > the > resource. If the media type remains unknown, the recipient SHOULD > treat it as type "application/octet-stream". ----------- That said, it would still be good to add some text about POST, Mark Barker said: ----------- > Oddly enough, the w3 draft spec for xmlhttprequest does not even state > that you should provide a content-type when posting: > http://www.w3.org/TR/XMLHttpRequest/#dfn-send > whereas XULPlanet at least states one should be provided: > http://www.xulplanet.com/references/objref/XMLHttpRequest.html#method_ > se > nd > "The MIME type of the stream should be specified by setting the > Content- Type header via the setRequestHeader method before calling send." > neither say what the default should be. That sounds like good advice to me. Any objections? Mark. ------------ If something like the description from XULPlanet about POST could be added, that would be great. I would be happy :-) Cheers David >-----Original Message----- >From: ext Bjoern Hoehrmann [mailto:derhoermi@gmx.net] >Sent: Wednesday, May 03, 2006 5:12 PM >To: Carson David (Nokia-TP-MSW/Boston) >Cc: public-webapi@w3.org >Subject: Re: handling of POST in XMLHTTPRequest. > >* <David.Carson@nokia.com> wrote: >>We have recently run into a case where XMLHTTPRequest is >being used to >>POST content, but the javascript author has failed to add the >mandatory >>content-type header. > >Hi David, thanks for brining this issue to the attention of >the Working Group. By mandatory do you mean RFC 2616 has a >MUST-level requirement to this effect? I thought it is a >SHOULD-level requirement except for the OPTIONS request, do >you agree? I got the following results when POSTing a simple string: > > Op9: text/xml;charset=utf-8 > FF2: application/xml > IE6: No header sent > IE7: No header sent > >For `null`: > > Op9: No header sent (though it doesn't appear to go into >readyState 4) > FF2: No header sent > IE6: No header sent > IE7: No header sent > >For a HTMLDocument (the current document) > > Op9: text/xml; charset=utf-8 (lower-case element names) > FF2: application/xml (upper-case element names) > IE6: Exception > IE7: Browser shuts down > >For the current application/xhtml+xml document > > Op9: text/xml;charset=utf-8 (proper casing) > FF2: application/xml (proper casing) > IE6: n/a > IE7: n/a > >For a separate DOMDocument (MSXML-based) > > Op9: n/a > FF2: n/a > IE6: text/xml;charset=UTF-8 > IE7: text/xml > >It seems these results hold true regardless of the content, >e.g. if the document in the last case contains non-ascii >characters like U+20AC the charset parameter is absent in the >IE7 request aswell, which is contrary to RFC 3023 and RFC >2616. Likewise, setting the Content-Type header to an XML type >for the simple string is fairly incorrect (the string I've >passed to it is not an XML document) and arguable incompatible with IE. > >It seems implementations should not set a Content-Type header >if the author didn't specify one for non-Documents, and for >Documents it should be the type of the Document, and if that >type is not known, and the Document supports the XML feature, >an XML media type. Does that make sense to you? >-- >Björn Höhrmann · mailto:bjoern@hoehrmann.de · >http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: >+49(0)621/4309674 · http://www.bjoernsworld.de >68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · >http://www.websitedev.de/ >
Received on Wednesday, 3 May 2006 21:46:22 UTC