[hunchentoot-devel] external-format and content-type question

[Vassilis Radis]

I recently had this problem:

I use sbcl + hunchentoot (current quicklisp supplied version) to serve
cl-who generated content that contains non-ascii range utf-8 chars (greek
letters). Initially i got the usual encoding error while processing a
request. So I found the  well known canonical solution: (setf
*hunchentoot-default-external-format* (flex:make-external-format :utf8
:eol-style :lf)). The result is that the browser (chrome) displayed garbage
where the greek letters should appear, although i set the default encoding
of chrome to UTF-8 and i include the utf-8 meta tag in the content. I saw
in the chrome tools that hunchentoot sent Latin-1 Http content-type header.
This showed me that I needed to send the content-type-header manually and
that Chrome (correctly IMO) ignores the user setting for the default
encoding, if it receives a different HTTP content-type type header. So I
set *default-content-type* and all is well now. But I came across
the (reply-external-format*) function which confused me.

Now, i am trying to clarify the functional co-relation or/and overlapping
between those three:
1.setting *hunchentoot-default-external-format*
2.setting (reply-external-format*)   --> is this just a per-request
override of the *hunchentoot-default-external-format*?
3.sending the content-type header. --> Is there any legal scenario where we
should report to the client something different than what is implied by
(reply-external-format*)? What is the point of a default content-type
header if there is a directly set default-external-format which also
implicitly designates the header we should send?

thanks in advance, Bill.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20111110/b6abb6a9/attachment.html>