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 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.

> >> > Please try the attached patch. If it doesn't help,
> >>
> >> browser immediately comes back with an error message about the proxy
> >> closing the connection
> >
> > I managed to get the logic wrong in a last-minute change. It should be:
> >
> > +         if (!data_is_available(fd, 0))
> > +         {
> > +            break;
> > +         }
> 
> That fixed it.  I haven't noticed any problems after hitting a lot of
> different web sites except for the change adding "http://" to the
> request log doesn't add "https://" for secure connections - for
> example:

That's because the client doesn't use https:// either.

> 2013-01-01 14:35:09.641 00000464 Request:
> http://www.epa.gov/radnet00/images/beta-gamma/baltimore-gamma.jpg
> 2013-01-01 14:35:21.513 00000ee8 Request: cdxnode64.epa.gov:443
> 
> 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.

> >> That works, but privoxy complains about 'The client side of the
> >> connection on socket NNN got closed without sending a complete request
> >> line.' when clicking on the link to the 2nd page.
> >
> > Please send me a a Privoxy log with:
> >
> > debug 1
> > debug 2
> > debug 4
> > debug 8
> > debug 16
> > debug 32
> > debug 128
> > debug 256
> > debug 512
> > debug 1024
> > debug 4096
> > debug 8192
> > debug 32768
> > debug 65536
> 
> I saved the log even tho everything seemed to work OK.  Still want it?

Only if you run into any other issues, thanks.

Fabian

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ 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_122512

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

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

iEYEARECAAYFAlDjYeIACgkQSMVSH78upWMkfACfT+KlUE8ay3iyzyii2r8jzXa/
liQAoItIKXcBBQswkh2D9WEhw+AD+aiU
=e5Wm
-----END PGP SIGNATURE-----