Re: Release date for Privoxy 3.0.20 beta

Lee <[email protected]> wrote:

> On 1/1/13, Fabian Keil <[email protected]> wrote:
> > Lee <[email protected]> wrote:
> >
> >> On 1/1/13, Fabian Keil <[email protected]> wrote:
> >> > Lee <[email protected]> wrote:
> >> >
> >> >> On 12/31/12, Fabian Keil <[email protected]> wrote:
> >> >> > Lee <[email protected]> wrote:
> >> >> >
> >> >> >> On 12/29/12, Fabian Keil <[email protected]> wrote:
> >> >> >> > I believe there are enough changes in CVS to warrant a new
> >> >> >> > release.
> >> >> >> >
> >> >> >> > As several of the changes are HTTP-related and affect pretty
> >> >> >> > much every request, I think it should be a beta.
> >> >> >> >
> >> >> >> > I propose we release Privoxy 3.0.20 beta in the middle of
> >> >> >> > January and 3.0.21 stable a couple of weeks later.
> >> >
> >> > New proposal: about 2 weeks after the Windows-specific issues are
> >> > fixed.
> >>
> >> Your latest patch fixed it, so it's still on track for middle of Jan :)
> >
> > Great. Patch committed.
> >
> > It would be good to also know if draining works as expected when
> > data is available, though.
> >
> > You can test this by configuring the client to aggressively pipeline
> > requests while using "tolerate-pipelining 0" (default) and frequently
> > loading websites without waiting for pages to load completely.
> 
> I probably didn't test this very well... pretty much every page has
> the an initial delay while the page contents are fetched and then it's
> displayed.  Very rarely does the firefox tab spinner icon continue to
> spin once the page is displayed, so there was very little time for me
> to click on a link before the page finished loading.

Great.
 
> >> It's just a cosmetic issue, but I suspect it's going to confuse people
> >> with some requests logged as "http://site..." and other requests
> >> logged as "site:443"
> >
> > That's probably true.
> >
> > It's a pretty recent change for feature request #3596294 and I don't
> > feel strongly about it. If we revert it, it should probably be reverted
> > before the release, though.
> >
> > In my opinion adding https:// isn't an option because Privoxy
> > neither knows that its actually https:// and even if it was,
> > the path would be missing. It might confuse less people, but would
> > also be technically wrong.
> 
> I'd go with technically wrong and less support requests/ user
> confusion pretty much every time :)

Technically wrong software makes me sad. So far the old correct
behaviour didn't seem to have a caused a lot of support requests
and thus should achieve both goals at the same time.

> >> I saved the log even tho everything seemed to work OK.  Still want it?
> >
> > Only if you run into any other issues, thanks.
> 
> I still see the "client side of the connection got closed" msg
> occasionally, but it doesn't seem to be causing any problems and every
> one I've checked has a long time between the last request & the
> connection being closed - for example:
> 
> 2013-01-03 21:04:08.500 00000cf8 Request:
> http://i1.blogs.msdn.com/themes/wireframe/Images/Weblogs/icon-rss.gif
> 2013-01-03 21:28:37.022 00000cf8 Error: The client side of the
> connection on socket 1736 got closed without sending a complete
> request line.

One the one hand it would be interesting to know if the client sent
any data at all for the request or how long the client connection was
open, but in general this situation doesn't necessarily imply a bug
in Privoxy (or the client) so as long as it doesn't affect the user
experience we can probably ignore it.

I also seem to get a couple of them myself every now and then:

fk@r500 ~/git/privoxy $grep "client side" /usr/jails/privoxy-jail/var/log/privoxy/privoxy.log
2013-01-02 19:02:55.744 801c09c00 Connect: The client side of the connection on socket 7 got closed without sending a complete request line.
2013-01-02 19:03:14.612 801c07c00 Connect: The client side of the connection on socket 7 got closed without sending a complete request line.
2013-01-02 19:03:33.829 801c08c00 Connect: The client side of the connection on socket 7 got closed without sending a complete request line.
2013-01-02 19:04:22.216 801c07800 Connect: The client side of the connection on socket 15 got closed without sending a complete request line.
2013-01-03 11:57:25.847 801c09000 Connect: The client side of the connection on socket 7 got closed without sending a complete request line.
2013-01-03 11:57:38.303 801c09800 Connect: The client side of the connection on socket 7 got closed without sending a complete request line.
2013-01-03 11:57:56.839 801c09400 Connect: The client side of the connection on socket 7 got closed without sending a complete request line.
2013-01-03 13:30:45.639 801c08000 Connect: The client side of the connection on socket 9 got closed without sending a complete request line.
2013-01-03 13:40:03.948 801c07400 Connect: The client side of the connection on socket 6 got closed without sending a complete request line.
2013-01-03 22:14:57.384 801c08000 Connect: The client side of the connection on socket 3 got closed without sending a complete request line.

It's interesting that the socket number distribution seems to be
highly uneven, so it might be the result of a some kind of connection
management done by Firefox.

For example optimistically sending "GET http://" and keeping the
connection idle until a new request has to be made and the complete
URL is known could cause this, although this seems like a somewhat
ridiculous performance optimisation.

I'll try to look into this before the release.

Fabian

------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812

_______________________________________________
Ijbswa-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ijbswa-developers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlDm2uwACgkQSMVSH78upWN2bgCcDL+rbWgQB4IRIw/tJfUksQXV
/x8An2OqUxZgji1nZTfQbjTskjvZUNwQ
=6Gk6
-----END PGP SIGNATURE-----