hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Weber (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-112) DefaultConnectionReuseStrategy misinterprets Connection header
Date Wed, 03 Oct 2007 05:57:50 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532007

Roland Weber commented on HTTPCORE-112:

Hi Oleg, Andrea,

this seems to be a case for the "small steps" approach. Let's start with those where we seem
to agree:

a) HeaderIterator and HttpMessage.headerIterator(String name)
b) HeaderElementIterator and an implementation based on Header.getElements()

I would then prepare for review:

c) TokenIterator and an implementation based on string parsing

Once c has been reviewed and either accepted or rejected, we can proceed with

d) Use whatever item iterator to interpret the "Connection" header

Oleg, there is no generic way of dealing with headers of all types. Headers are defined with
varying syntax in RFC 2616, more headers are defined in other specs, and anyone is free to
add even more headers not specified publicly anywhere. For starters, the HeaderElement parsing
works only on headers that are allowed to have multiple elements. What happens if somebody
uses it for the Referer: header with a URL like "http://where.ever/what/ever;jsessionid=6894236837268"?
It returns garbage.
Some of the headers in RFC 2616 are defined as lists of plain tokens, not of generic header
elements. Plain tokens are a subset, but by parsing them with the more generic format, we'd
be accepting invalid input. Like "Connection: close=false" or "Connection: close; q=0" or
similar nonsense.

Andrea, you'd be asking too much of the parser framework if that had to decide about the syntax
of specific headers. There is a general syntax that all headers have to follow, which is implemented
by the parser framework. That's just enough to split a header into name and value. Then there
are some commonly used syntaxes for header values. One example is the generic header elements
format that is currently supported by the parser framework. Another example is the plain token
list, that I an now suggesting to support explicitly.
The syntax of a header value depends on the header name, and it really is the code that interprets
the value that knows what format the value has to be in. Code that expects a header value
in the generic elements format can use Header.getElements(), or will be able to use the HeaderElementsIterator.
Code that expects a header value in the plain token list format could use the TokenIterator.
If somebody chooses to use the wrong interpretation for a specific header, they'll get garbage
or ParseExceptions. I don't see how we could avoid that.


> DefaultConnectionReuseStrategy misinterprets Connection header
> --------------------------------------------------------------
>                 Key: HTTPCORE-112
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-112
>             Project: HttpComponents Core
>          Issue Type: Bug
>          Components: HttpCore
>    Affects Versions: 4.0-alpha5
>            Reporter: Roland Weber
>            Priority: Minor
>             Fix For: 4.0-beta1
>         Attachments: multiuconn.patch
> DefaultConnectionReuseStrategy assumes that "Connection:" is a single-valued header.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

View raw message