On Sun, 2015-02-08 at 14:14 -0800, Sean Shubin wrote: > I get the advantages of SLL, but publicsuffix is above and beyond SSL, and > is also not built in to browsers, so that does not address my central > question of: > "Why should an http client library be unable to execute an HTTP GET to a > location that any web browser can?" > > What I perceived as a problem was that we have an http client library > applying different rules than http browsers. Then again, perhaps all > of the browsers are wrong in this regard, and have not gotten around to > integrating the publicsuffix rules. > > I don't really want to debate what the apache http client library should > do, I am more interested in understanding the priorities, so I can decide > if it is suited to my needs. > > Should an http client library be a simple abstraction over HTTP? In this > case it is really easy to automate anything a browser can do, but you don't > get the additional security of enforcing the publicsuffix rules. > Or should the http client library be smart enough to enforce rules that > browsers do not? In this case the publicsuffix rules are enforced for > free, but since the behavior is different than that of http browsers, you > won't be able reliably automate http browsers. >
HC goal is to provide an HTTP protocol compliant transport library and not to emulate the behavior of so called common browsers. Oleg > > > On Sun, Feb 8, 2015 at 3:45 AM, Oleg Kalnichevski <[email protected]> wrote: > > > On Fri, 2015-02-06 at 13:21 -0800, Sean Shubin wrote: > > > Thanks for the information, I looked over publicsuffix.org. > > > > > > I am still not following the connection between an alternative subject > > name > > > being "too broad", and an http client failing to execute an HTTP GET > > > request. What is the advantage? > > > > What is the advantage of SSL hostname verification or SSL security in > > general? > > > > Oleg > > > > > Why should an http client library be > > > unable to execute an HTTP GET to a location that any web browser can? > > > > > > On Fri, Feb 6, 2015 at 2:03 AM, Oleg Kalnichevski <[email protected]> > > wrote: > > > > > > > This makes 'githubusercontent.com' a public name space like 'com' > > > > or 'co.uk'. Based on that HC 4.4 cannot accept > > > > '*.githubusercontent.com' alternative subject name as being too broad. > > > > For details see > > > > https://publicsuffix.org/ > > > > > > > > Oleg > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
