W3C home > Mailing lists > Public > www-talk@w3.org > May to June 2006

Re: Is there any ongoing work on HTTP?

From: Maurice Smulders <msmulders@novell.com>
Date: Wed, 10 May 2006 13:36:46 -0600
Message-Id: <4461EC6E.E0A8.0060.0@novell.com>
To: "Nic" <nferrier@tapsellferrier.co.uk>
Cc: <sh@defuze.org>,<www-talk@w3.org>

So, what would be a way to make sure the charset of the post data is a
certain format. When I look with Live Http Headers on my firefox
browser, it includes 

Accept-Charset: ISO-8859-1,utf-8; q=0.7; q=0.7 

But if this is a 'recommendation' for the server, it does not tell
anything about the charset used by the actual post data. 
Is there a way in the protocol to find that out, or a way to force the
browser to respond in a certain charset? 



>>> Nic <nferrier@tapsellferrier.co.uk> 05/10/06 12:49 PM >>>
Maurice Smulders <msmulders@novell.com> writes:

> Hello,
> There is one more big deficiency IMHO:
> A POST response does not include the code page of the response.
> i.e. The code page of response is depended on one of the following
> settings
> 1) Browser setting
> 2) Char set settings in header
> 3) Char set settings in Meta tag
> 4) %Charset in DTD
> 5) Accept-Charset in Form tag.
> For intermediate proxies interpreting the information, this is very
> difficult. This is going to be much more an issue with
> internationalization... Even if a proxy would be maintaining the state
> across a request, the browser setting is the one which is the most
> difficult to figure out...
> I can see one intermediate solution, and that is to write some
> javascript which queries the browser for that information, and builds
> x- header with that in it. But I think the better solution would be a
> standardized method which all browsers have to support...
> This one seems to be between the HTTP and HTML spec, and kinda fell
> between the cracks?

I don't believe you are right.

First off, code pages are not part of the HTTP spec. Character sets

Second, the charset can (and should) be specified for an entity
included in a response to a POST request. It is specified with the
content-type as it is for any other entity response.

Third, the content negotiation tools you mention (Accept-Charset,
etc...) are suggestions to the server: not decisions about what
charset the returned data actually is encoded in.

It is bad form but acceptable to have the following conversation:

  POST /someplace HTTP/1.1
  Accept-Charset: utf8

  HTTP/1.1 201 Created
  Content-type: text/html;charset=iso-8859-1

Fourth, I'm not even aware that ommiting the content type on responses
to a POST is a particularly common thing to do. I can't remember the
last time I saw it happening.

Nic Ferrier
Received on Wednesday, 10 May 2006 19:53:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:06 UTC