I recently had this problem:<div><br></div><div>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.</div>
<div><br></div><div>Now, i am trying to clarify the functional co-relation or/and overlapping between those three:</div><div>1.setting *hunchentoot-default-external-format*</div><div>2.setting (reply-external-format*)   --&gt; is this just a per-request override of the *hunchentoot-default-external-format*?</div>
<div>3.sending the content-type header. --&gt; 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? </div>
<div><br></div><div>thanks in advance, Bill.</div>