I don't think the sending back [] is of any use to man nor beast. From the w3c specification:
"""If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server SHOULD send an error response with the 406 (not acceptable) status code, though the sending of an unacceptable response is also allowed.""" (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html)
So, we have two choices:
1) send default_zpublisher_encode, which defaults to Latin-15 if not set explicitly
2) explicitly set UTF-8 as the comments in http.py propose for other situations
While I would like default_zpublisher_encode to default to UTF-8 and use that I can imagine such a change potentially causing problems for ZMI work and should be handled separately. I propose, therefore, to return UTF-8 where the client does not set this header.
I don't think the sending back [] is of any use to man nor beast. From the w3c specification:
"""If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server SHOULD send an error response with the 406 (not acceptable) status code, though the sending of an unacceptable response is also allowed.""" (http:// www.w3. org/Protocols/ rfc2616/ rfc2616- sec14.html)
So, we have two choices:
1) send default_ zpublisher_ encode, which defaults to Latin-15 if not set explicitly
2) explicitly set UTF-8 as the comments in http.py propose for other situations
While I would like default_ zpublisher_ encode to default to UTF-8 and use that I can imagine such a change potentially causing problems for ZMI work and should be handled separately. I propose, therefore, to return UTF-8 where the client does not set this header.