Hans,<div><br></div><div>Thank you for your quick answer.</div><div><br></div><div>The only blur thing for me now is:</div><div>How exactly hunchentoot understands what kind of content-type my handler's return string contains?</div>
<div><br></div><div>Thanks,</div><div>Bill</div><div><br></div><div> </div><div><br><div class="gmail_quote">On Thu, Nov 10, 2011 at 4:12 PM, Hans Hübner <span dir="ltr"><<a href="mailto:hans.huebner@gmail.com">hans.huebner@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Bill,<br>
<br>
Let me try to answer your question with a description of how external<br>
formats in Hunchentoot are supposed to work. I am talking about<br>
Hunchentoot 1.2.0 specifically, as the behavior has changed since the<br>
1.1 release family in the hope of making it easier to understand and<br>
use.<br>
<br>
External formats are meant to mostly work automatically. It should be<br>
enough to select a proper external format for the character set that<br>
you normally use and set *hunchentoot-default-external-format* to<br>
that. The new default character set since 1.2.0 is :utf-8, so most<br>
standard use cases should be covered.<br>
<br>
Also new with 1.2.0 is Hunchentoot's ability to automatically report<br>
the encoding used in replies sent. This is done by adding a charset=<br>
attribute to the reply content type, but only if the content type is a<br>
subtype of "text" (i.e. it does not affect, say, application/xml).<br>
This is independent of the *hunchentoot-default-external-format*<br>
setting, i.e. you can set (reply-external-format*) in your handler to<br>
something different from the default and still see the right charset<br>
be added to the content-type, if it is text.<br>
<br>
All this works for handlers that return strings, i.e. if you handler<br>
returns an octet vector or directly writes to the response stream, you<br>
are responsible for setting up the content-type in the reply properly<br>
yourself.<br>
<br>
If this does not work, please supply us with a specific case where and<br>
how it does not.<br>
<br>
Thanks!<br>
Hans<br>
<div><div class="h5"><br>
On Thu, Nov 10, 2011 at 2:42 PM, Vassilis Radis <<a href="mailto:radisb@gmail.com">radisb@gmail.com</a>> wrote:<br>
> I recently had this problem:<br>
> I use sbcl + hunchentoot (current quicklisp supplied version) to serve<br>
> cl-who generated content that contains non-ascii range utf-8 chars (greek<br>
> letters). Initially i got the usual encoding error while processing a<br>
> request. So I found the well known canonical solution: (setf<br>
> *hunchentoot-default-external-format* (flex:make-external-format :utf8<br>
> :eol-style :lf)). The result is that the browser (chrome) displayed garbage<br>
> where the greek letters should appear, although i set the default encoding<br>
> of chrome to UTF-8 and i include the utf-8 meta tag in the content. I saw in<br>
> the chrome tools that hunchentoot sent Latin-1 Http content-type header.<br>
> This showed me that I needed to send the content-type-header manually and<br>
> that Chrome (correctly IMO) ignores the user setting for the default<br>
> encoding, if it receives a different HTTP content-type type header. So I<br>
> set *default-content-type* and all is well now. But I came across<br>
> the (reply-external-format*) function which confused me.<br>
> Now, i am trying to clarify the functional co-relation or/and overlapping<br>
> between those three:<br>
> 1.setting *hunchentoot-default-external-format*<br>
> 2.setting (reply-external-format*) --> is this just a per-request override<br>
> of the *hunchentoot-default-external-format*?<br>
> 3.sending the content-type header. --> Is there any legal scenario where we<br>
> should report to the client something different than what is implied by<br>
> (reply-external-format*)? What is the point of a default content-type header<br>
> if there is a directly set default-external-format which also implicitly<br>
> designates the header we should send?<br>
> thanks in advance, Bill.<br>
</div></div>> _______________________________________________<br>
> tbnl-devel site list<br>
> <a href="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</a><br>
> <a href="http://common-lisp.net/mailman/listinfo/tbnl-devel" target="_blank">http://common-lisp.net/mailman/listinfo/tbnl-devel</a><br>
><br>
<br>
_______________________________________________<br>
tbnl-devel site list<br>
<a href="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/mailman/listinfo/tbnl-devel" target="_blank">http://common-lisp.net/mailman/listinfo/tbnl-devel</a><br>
</blockquote></div><br></div>