You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Albretch Mueller <lb...@gmail.com> on 2011/01/16 17:19:36 UTC
peer review for RFE ...
~
As we well know, (RFC 616: 5.3, 6.2; RFC 822: 3.1, RFC: 4229),
servers do not send response headers metadata ordered in any
particular way. They are just a bag of {property:value} text strings
of ISO-8859-1 characters. Response headers may include extra
("experimental", unrecognized and/or undefined, but useful) metadata.
Nonetheless, due to configuration settings and type of data feed,
particular servers are pretty consistent in what type of response
headers metadata they send
~
Indexing the (known) response headers sent by a particular site may
be helpful for proxies, RSS readers and caching mechanisms, which
could then use (indexed) command objects to process the received data
for consistency, sanity and/or marshall the data to be inserted into a
DB (using PreparedStatements), a(n entity referenced) log, a csv file,
...
~
In short: org.apache.http.Header.[BasicHeaderElement,
BufferedHeader]{ .getName(), .getValue(), .getElements()} are not
enough.
~
Some sort of org.apache.http.Header.Sorted[BasicHeaderElement,
BufferedHeader] with defined { .get_SORTED_Elements(),
get_SORTED_BAGS_OF_Elements()} would be very useful
~
Of course the sorting preference should be specified via a:
~
org.apache.http.Header.Sorted[BasicHeaderElement,
BufferedHeader].setSortOrderContext(String[][] aSrtPrefs)
~
where aSrtPrefs would look like:
~
aSrtPrefs = new String[][]{
{"Content-Length"}
,{"Content-Type"}
,{"Set-Cookie", "UserID", "Max-Age", "Version"}
,{"ETag"}
,{"Last-Modified"}
,{"Expires"}
};
~
The first aSrtPrefs[*][0] element of the arrays would always be the
name and the continuing elements would specify which type or response
headers one cares to process and in which order they should be
~
So .get_SORTED_BAGS_OF_Elements() would return an array of value
object looking like this:
~
class SortedHeadersBag{
String aHeaderName;
BasicNameValuePair[] aSortedHeaderNames; // (as specified in
setSortOrderContext(String[][] aSrtPrefs))
BasicNameValuePair[] aExtraHeaderNames; // rest unspecified Headers
as they were received by the server
}
~
I see HC developers hang out here (in the users list) too. Since they
are the ones keeping a mental map of the whole project and devoting
themselves to it, it is best if we discus the utility of such (not
that basic (but not that advanced either)) implementations and then
they commit the enhancements to the code themselves
~
lbrtchx
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: peer review for RFE ...
Posted by Albretch Mueller <lb...@gmail.com>.
~
if the headers are being parsed anyway as part of the initial
client-server negotiation, it would be great if the most amount of
juice is squeezed at once as part of the parsing, instead of then
figuring things out (-parsing again- (sometimes repeatedly in code I
have read)) the result of Header.getValue()
~
There are a number of issues with that (re)implementation I am sure
you will see, for example, if for some reason some server's changes
have been made and the set parsing context does not match the response
headers a NotMatchedHeadersParsingContextException should be thrown,
but if the extra Header Names of the bag if not matched just a warning
should be logged
~
lbrtchx
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: peer review for RFE ...
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2011-01-16 at 16:19 +0000, Albretch Mueller wrote:
> ~
> As we well know, (RFC 616: 5.3, 6.2; RFC 822: 3.1, RFC: 4229),
> servers do not send response headers metadata ordered in any
> particular way. They are just a bag of {property:value} text strings
> of ISO-8859-1 characters. Response headers may include extra
> ("experimental", unrecognized and/or undefined, but useful) metadata.
> Nonetheless, due to configuration settings and type of data feed,
> particular servers are pretty consistent in what type of response
> headers metadata they send
> ~
> Indexing the (known) response headers sent by a particular site may
> be helpful for proxies, RSS readers and caching mechanisms, which
> could then use (indexed) command objects to process the received data
> for consistency, sanity and/or marshall the data to be inserted into a
> DB (using PreparedStatements), a(n entity referenced) log, a csv file,
> ...
> ~
> In short: org.apache.http.Header.[BasicHeaderElement,
> BufferedHeader]{ .getName(), .getValue(), .getElements()} are not
> enough.
> ~
> Some sort of org.apache.http.Header.Sorted[BasicHeaderElement,
> BufferedHeader] with defined { .get_SORTED_Elements(),
> get_SORTED_BAGS_OF_Elements()} would be very useful
> ~
> Of course the sorting preference should be specified via a:
> ~
> org.apache.http.Header.Sorted[BasicHeaderElement,
> BufferedHeader].setSortOrderContext(String[][] aSrtPrefs)
> ~
> where aSrtPrefs would look like:
> ~
> aSrtPrefs = new String[][]{
> {"Content-Length"}
> ,{"Content-Type"}
> ,{"Set-Cookie", "UserID", "Max-Age", "Version"}
> ,{"ETag"}
> ,{"Last-Modified"}
> ,{"Expires"}
> };
> ~
> The first aSrtPrefs[*][0] element of the arrays would always be the
> name and the continuing elements would specify which type or response
> headers one cares to process and in which order they should be
> ~
> So .get_SORTED_BAGS_OF_Elements() would return an array of value
> object looking like this:
> ~
> class SortedHeadersBag{
> String aHeaderName;
> BasicNameValuePair[] aSortedHeaderNames; // (as specified in
> setSortOrderContext(String[][] aSrtPrefs))
> BasicNameValuePair[] aExtraHeaderNames; // rest unspecified Headers
> as they were received by the server
> }
> ~
> I see HC developers hang out here (in the users list) too. Since they
> are the ones keeping a mental map of the whole project and devoting
> themselves to it, it is best if we discus the utility of such (not
> that basic (but not that advanced either)) implementations and then
> they commit the enhancements to the code themselves
Albretch
Dev list would have probably been a better venue for discussing this
issue.
I am still unsure I understand the reason why the existing API as not
'enough' to cover your particular case, as one can surely transform
unordered bag of headers returned by the framework into a more complex
structure without having to re-parse message headers. Message headers
are lazily parsed anyway, so even if one has to employ a different
parsing routine message headers do not need to be parsed more than once.
Overall, I feel that while this concept can certainly be useful for
certain type of applications, I am not convinced it is generic enough to
warrant inclusion into the framework itself, as it can be built on top
of the existing API without much efforts (unless I am missing something
important).
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org