Re: Raw HTTP Headers

How does it modify the headers -- just trimming whitespace?

My view on this is that we should record the entire response,
verbatim, in a CDATA section, Base64 encoded per EARL (or not), and
then feel free to embrace all kinds of normalization and parsing in
the moki document.

You've got the original stashed away for the record, and then the
useful, parsed version in the moki document.

So: no I'd rather not be bothered by this.

PS but if you spotted chapter and verse from the HTTP spec and the
client seems to not follow it exactly, I'm happy to file a bug report
and/or submit the patch, separately. Givin' back to the community and
all that...

Sean


On 5/24/07, Jo Rabin <jrabin@mtld.mobi> wrote:
>
> We are currently assuming that moki will record the raw HTTP headers.
>
> HttpClient in Jakarta Commons doesn't do that. The question is, do we
> want to modify it so it does, or can we live without it.
>
> In favour of living without it is, well, that it's no work. In favour of
> having it, is that we are closer to being able to resolve questions of
> mal-formed headers.
>
> A quick review of the code shows that the headers are parsed in
> HttpParser, and that even if you have a so-called wire trace enabled
> this just serialises the parsed headers (in HttpMethodBase).
>
> readLine is the method of HttpParser that we'd want to change to record
> the raw data, I think. A trivial change I think. Though not sure I'd
> know how to go about doing it.
>
> Jo
>
> PS Incidentally, if you are interested you will see that in parseHeaders
> the treatment of lines starting with space or tab appears to be faulty.
> Firstly because it allows a whitespace only line to end the headers,
> rather than an empty line, and secondly because I think it messes up
> handling of lines starting with space or tab - which are supposed to be
> continuations of the previous header. If there was no previous header,
> that is an error, I think, which it does not detect.
>
>

Received on Thursday, 24 May 2007 19:26:13 UTC