Re: Release date for Privoxy 3.0.20 beta

Ian Silvester <[email protected]> wrote:

> 
> On 2013-01-01, at 5:23 PM, Fabian Keil 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:

> >>> 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.
> 
> Tested with no issues on OS X.

Great.

Out of curiosity, are you also using (or interested in using)
tools/privoxy-regression-test.pl for general testing,
or do you test mainly manually?

My impression is that privoxy-regression-test.pl is not used
as often as it could be and I'm wondering if more documentation
could help here.

> I'll now proceed to build the set of OS X packages ready for the word
> to release 3.0.20. Obviously if we revert the feature request 

The last sentence seems to be incomplete?

> >> 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.
> 
> If it's not possible to make the log entries fully consistent
> (i.e. to add the protocol in all instances) then my opinion is to
> revert this change, and indeed to modify the code such that no log
> entries display the protocol specifier. Unless of course this means
> that the host operating system cannot interpret the URLs and therefore
> no longer makes them clickable?

I believe reverting the change would indeed make them unclickable
again on Windows, but changing RE_URL in win32log.c could probably
make them clickable again, provided this is something someone wants
to work on.

In the grand scheme of things that are currently suboptimal in
Privoxy's windows-specific code this seems like a trivial issue
to me, though.

My impression now is that there's a rough consensus that jcc.c,v 1.422
on its own potentially causes more problems than it solves, so we should
probably revert it for now and think about a better solution after the
next stable release.

Fabian

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712

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

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

iEYEARECAAYFAlDlYAoACgkQSMVSH78upWN9kQCdGAfNPNcPztJ1QhVWYrAJqA08
NF4AoIih9c+Isif5fJzEhCrvPLCFCwUH
=fJM+
-----END PGP SIGNATURE-----