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 Mon, 01 Oct 2007 17:45:50 GMT

    [ 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


Mime
View raw message