[rfc][icedtea-web] disconnecting httpurlconnections

[Omair Majid]

* Andrew Azores <aazores at redhat.com> [2014-05-02 10:42]:
> On 05/02/2014 10:25 AM, Omair Majid wrote:
> >* Jiri Vanek <jvanek at redhat.com> [2014-05-02 09:34]:
> >>I will elaborate a bit more, but if you may say few more words, it
> >>would be nice:((
> >Sorry, but I know next to nothing about this area. All I know is that
> >Adam looked into it and decided that disconnect() is best avoided.
> 
> Maybe I'm just missing something but I really don't see how he came
> to the conclusion that disconnect() should be avoided... the initial
> problem seems to be that a new connection was being made and only
> the response code being read, nothing else. The proposed solution
> was to do this but then close the connection. The comment Adam
> refers to states that rather than simply disconnecting after reading
> the response code, the connection should actually do something -
> consume and discard it, or simply use a HEAD request in the first
> place - so as to not confuse these "mediocre" web servers (which
> presumably are expecting a GET request to actually want the response
> body, so they hang on sending it unless interrupted by a
> disconnect). Adam himself even says that it's difficult to actually
> reuse connections, which is AFAICT the reason they weren't
> disconnected to begin with. Why would it not be correct to both (1)
> use HEAD request with consume/discard fallback, (2) disconnect when
> finished, if the connection is not going to be reused later? As Jiri
> says, is the overhead incurred by creating new connections really
> that bad that we should deal with evidently flaky connection reuse?

Your explanation does make sense. My knowledge of this topic is very
rudimentary and is pretty much limited to recalling that Adam avoided
calls to disconnect.

If the makes sense to you, then no objections from me.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681