I think it is silly to conduct a conversation in two channels. Anyway: The applicability of the charset attribute in content type specifications is restricted to text content types as per rfc2045. At least that is my reading of it.
Now, there is nothing wrong with being liberal in accepting, but in this case I actually tend to make RAW-POST-DATA return an octet vector for non-text content types and have the application handle the desired decoding.
-Hans
On Mon, Oct 31, 2011 at 3:44 PM, John DeSoi desoi@pgedit.com wrote:
Hans,
On Oct 31, 2011, at 10:11 AM, Hans Hübner wrote:
I have continued the topic on github, even though the issue is closed.
Hunchentoot makes no attempt in determining the content type for non-text bodies. I think that the piece of code that you've posted does the right thing. I also think that RAW-POST-DATA should return the body as octet vector rather than making a possibly false attempt at guessing the character set. If you have another suggestion, please let us know.
Does not the fact that charset is provided, tell you that it is textual? There is nothing magic about the mime time having "text" in it. I think there are a lot of mime types that are textual that don't have "text" as the subtype. In all cases Hunchentoot is going to give you the wrong character type by default (unless it matches by luck). The handler I provided is not a complete solution because, I assumed UTF-8 which is incorrect. Other character sets are allowed. To handle any text request correctly (that does not have "text" in the mime type), the handler will need to parse the charset itself. This repeats what Hunchentoot has already executed, but ignored because "text" was not in the mime subtype.
This is not a big deal and I can work around it. But I suspect it will come up again in the near future :).
Thanks for your feedback,
John DeSoi, Ph.D.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel