Re: cvs commit: jakarta-tomcat-connectors/webapp/docs/images packet1.gif

[Pier Fumagalli <pi...@betaversion.org>]

"pier@apache.org" <pi...@apache.org> wrote:

> + <li>
> +   <b>generic string</b>: a generic string follows the same structure
> +   defined for RAW, but the byte sequence is a US-ASCII encoded
> +   representation of a string, as outlined in the HTTP/1.1 specification
> +   (<a href="http://www.rfc-editor.org/rfc/rfc2616.txt">RFC-2616</a>)
> +   for everything but request and response bodies and header values
> +   (field identifier <b>STRING</b>).
> + </li>
> + <li>
> +   <b>mime string</b>: a mime string is exactly as a generic string,
> +   but its byte-representation is supposed to be ISO-8859-1 encoded,
> +   and must follow the rules defined by the HTTP/1.1 protocol
> +   specification section 2.2 for TEXT (used by header values) referring
> +   to <a href="http://www.rfc-editor.org/rfc/rfc2047.txt">RFC-2047</a>
> +   (Message Header Extension for Non-ASCII Text). Thus (for example)
> +   the string "I love Japan" with the word "Japan" translated in Japanese
> +   and encoded in Shift_JIS would be represented as: <b>"I love
> +   =?Shift_JIS?q?=e6=97=a5=e6=9c=ac?="</b> (field identifier <b>MIME</b>).
> + </li>

Folks (of the connector family)... Would like to point you out how things
are supposed to be handled by HTTP... Generic string is all how the first
request line, the first response line and the header names are encoded, mime
string is how header values are encoded...

Since i18n is quite important (at least for my employer) doublecheck that
the connectors behave _like_this_ (as the spec says)...

I'm taking care of WebApp on that part (in the final release of the
protocol, anyway).

Remm, it should be fairly trivial to do the right modifications in Coyote,
also, do we want to add another couple of tests to check out this particular
stuff?

    Pier


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>