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: [email protected]
For additional commands, e-mail: [email protected]
