hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 35148] - URI.parseUriReference treats strings with leading ':' as absolute URIs with zero-length scheme
Date Thu, 02 Jun 2005 18:59:14 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35148>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35148





------- Additional Comments From gojomo@archive.org  2005-06-02 20:59 -------
I would suggest that web browser behavior is a valid and important source of
input, along with formal specifications.

(1) While HTTPClient is not a "web browser", one of its key uses is in creating
web browsers and stand-ins for web browsers (like crawlers). Indeed, the
HTTPClient project home page, when listing examples of "HTTP-aware client
applications" that may find HTTPClient "of interest", lists "web browsers" first. 

(2) While HTTPClient is not a "web browser", all "web browsers" are themselves
HTTP client applications. Their behavior in aggregate establishes what users and
server/app developers expect. The major browsers individually, and all browsers
together as a class, have much more developer and user attention (and QA and
usability testing) than HTTPClient, and so often encode within their established
practices a lot of hard-won wisdom about the most beneficial and
broadly-compatible interpretation of specs. In a case like this, where the specs
could plausibly be read more than one way, browsers are likely to have
encountered the ambiguity and forced the issue one way or the other first. 

(3) There are both "standards" from formal specs, and de facto "standards" that
emerge from consensus practice, even if never formally specified. Both are
important, and in the HTTP domain, web browsers are the major force in
establishing the de facto standards. A library that only implements the formal
standards is interesting for some purposes but not others. 

(4) HTTPClient's "compatibility" mode for cookies already emulates browser
tolerance of nonstandard server/app cookie formats, so that servers see what
they would expect to get on followup hits from widely-deployed browsers. That
same pragmatic approach of accomodating the browser lead would make sense here.
For example, if a web page specifies a background image as relative URI
":bg.jpg", and popular web browser http client software like IE and Firefox both
resolve this relatively and display it properly (and they do!), that should
factor in for how HTTPClient decides to interpret such URIs, even if some
wordage in the specs suggest another way. 

I'm not saying browser behavior trumps all other considerations, but it should
not be ruled out as one valid and pragmatic criterion.  

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message