Re: Release date for Privoxy 3.0.20 beta

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.

In any case, go to "about:config" in firefox, enable everything with
"pipelining" in the name and start visiting web pages.  I kind of got
sidetracked trying to see how many open connections I could get, but
everything seemed to work OK until I managed to configure FF to open
more connections than privoxy would allow.


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

I'd go with technically wrong and less support requests/ user
confusion pretty much every time :)


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

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.

I'll probably change it back to LOG_LEVEL_CONNECT in a day or two if I
continue with no problems.

Lee


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