Hello folks,

OT1H, the charset and external format of a request are extracted from the Content-Type header and used to percent-decode post parameters in the function maybe-read-post-parameters.

OTOH, get parameters are always 1) initialized in the method #<initialize-instance :after (request) >, 2) percent-decoded using *hunchentoot-default-external-format*.

That works fine when all pages of the site use a the same external format - just setting *hunchentoot-default-external-format* globally is enough.

But if one wanted various pages to be in different formats, that could be inappropriate. For now, it is even buggy because within the current flexi-streams version, the decode error is not suppressed by following code:

(let ((*substitution-char* #?)) (form-url-encoded-list-to-alist (split "&" query-string)))

I have bumped into all this while trying to process forms in the :windows-1251 external format.

AFAIK, user agents percent-encode get parameters using in the charset specified in the previous server response. Without post parameters, user agents do not supply the charset in Content-Type as a rule. Thus only a Hunchentoot request handler can definitely know what the charset is actually.

All that means that we should postpone retrieval of get parameters as far as possible. Maybe it is worth not to specify the :initform for the get-parameters slot and leave it unbound? Then we could initialize this slot with the following:

(defmethod slot-unbound (class (request request) (slot-name (eql 'get-parameters))) (setf (slot-value request 'get-parameters) (form-url-encoded-list-to-alist (split "&" (query-string request)) (request-external-format request))))

The only question is how to compute such a request-external-format. Any takers? -- Sincerely, Dmitriy Ivanov lisp.ystok.ru