[
https://issues.apache.org/jira/browse/HTTPCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531578
]
Roland Weber commented on HTTPCORE-112:
---------------------------------------
Hello Andrea, Oleg,
I was also thinking along the Iterator line. It would avoid parsing and
splitting all headers just to get at a single token value. A header iterator
alone would not add much value over the current Header[] getHeaders(String
name). I'm not that fond of using the HeaderElement concept and parsers for
that purpose, since that supports a much more complex header syntax and creates
more objects to represent the elements.
When I browsed through the core a few weeks ago, I stumbled on three instances
where lists were not handled according to the specification (HTTPCORE-112,
HTTPCORE-115, HTTPCLIENT-688). In all three cases, the list elements are plain
tokens as in RFC 2616, section 2.2. No parameters, no comments, no quoting, no
escape sequences. Just plain non-whitespace characters. I believe that a
special treatment of this simple case would be appropriate. My latest ideas
were as follows:
interface HeaderIterator extends Iterator {
boolean hasNext();
Header nextHeader();
}
interface TokenIterator extends Iterator {
boolean hasNext();
String nextToken();
}
interface HttpMessage {...
HeaderIterator headerIterator(); // replacing the current one
HeaderIterator headerIterator(String name);
}
class SimpleTokenIterator implements TokenIterator {
SimpleTokenIterator(HeaderIterator) {...}
}
The HeaderIterator implementation can be given access to the header array
stored in the message, to avoid creating an intermediate array and the
temporary objects used to assemble that array. The HeaderIterator interface
serves an additional purpose: J2ME doesn't include the java.util.Iterator
interface. By defining our own extension and not using the base interface, we'd
allow for API compatibility with a possible J2ME version of HttpCore. We might
throw in a TokenIteratorFactory, but that's goldplating already.
Andrea, if you'd like to work on a patch in this direction, that would be great.
But don't feel obliged. I'd take care of it myself in time for the beta.
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]
