[
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.
cheers,
Roland
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
