[jira] Commented: (HTTPCORE-112) DefaultConnectionReuseStrategy misinterprets Connection header

["Roland Weber (JIRA)" <ji...@apache.org>]

    [ 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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org