Re: Is there any ongoing work on HTTP?

Nic, 

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? 

Thanks, 

Maurice 

>>> 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
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
a
> 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
are.

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
http://www.tapsellferrier.co.uk