Re: Release date for Privoxy 3.0.19 stable

Lee <[email protected]> wrote:

> On 12/29/11, Fabian Keil <[email protected]> wrote:
> > Lee <[email protected]> wrote:

> >> Does the internal pcre version have modifications to handle the host
> >> part of regular expressions in the action files or is it two separate
> >> functions?  eg
> >> .example.com/
> >> matches any host name ending in ".example.com".  A normal [??] RE
> >> would treat the periods as match any single character.  Privoxy
> >> doesn't treat periods as wildcards until after a "/" character.
> >
> > No such modifications are necessary as Privoxy doesn't use
> > pcre for the host part of the URL pattern at all,
> 
> ??
> It seems like it has to use something since it isn't a straight text match..
> Oh well, I'll try to follow the code & figure it out

Have a look at host_matches() in urlmatch.c.

> > unless it has
> > been configured to do so with --enable-extended-host-patterns.
> >
> > Quoting the description:
> > | Enable and require PCRE syntax in host patterns. This feature hasn't
> > | been announced yet and it's not clear if it's a good idea. It's expected
> > | to work, but undocumented. You should only enable it if you know what
> > | PCRE is and are sure that you need it for your host patterns. You can
> > | use tools/url-pattern-translator.pl to convert existing action files to
> > | use PCRE host patterns. Please don't enable this option when creating
> > | packages for others that may not be expecting it.
> >
> > TODO list item #80 is also relevant:
> >
> > | Change FEATURE_EXTENDED_HOST_PATTERNS to support both
> > | extended and vanilla host patterns at the same time.
> 
> Right, that one - "vanilla host patterns".  That's not a [modified?]
> PCRE package?

No, the entire code for it is in urlmatch.c and does
not rely on pcre at all.

While pcre is always used for the path of the URL,
no Privoxy-specific modifications for pcre are
necessary there either.

> Where I was trying to go with the question was finding out if there's
> two separate packages - "host patterns" and whatever comes after the
> host part.  If it's all one package with modifications for matching
> host patterns then upgrading to the current PCRE libs + backporting
> Privoxy modifications to the library is going to be *much* harder.
> 
> If it's two separate packages there's a slightly better chance I can
> figure out how to upgrade the windows version of Privoxy to the
> current pcre library.

It should in theory work similar to the way the external
zlib is used:

1. Install a recent pcre version and its header files.
2. Figure out a way to convince configure that a dynamic
   pcre version is available. It might work out of the box
   or require some fiddling.
3. Get it to compile. Again, it might just work. 
4. Figure out a way to get the compiled binary working
   when installed from a package. This might require
   shipping a dll for pcre.

The alternative would be to update "our" pcre version
and to continue statically compiling pcre into the
Privoxy binary.

>    [.. snip domain regex possible options ..]
> >> >> > Interesting. We probably shouldn't use that define when
> >> >> > --disable-ipv6-support has been used anyway.
> >> >>
> >> >> Probably not.. dunno if it's worth the effort to redo the code when we
> >> >> could just do a
> >> >> #ifndef NI_MAXSERV
> >> >
> >> > Using our own define, naming it to something like
> >> > MAX_PORTSTRING_LENGTH and setting it to NI_MAXSERV
> >> > if it's available, and 32 otherwise, would also make
> >> > the code easier to read (I think), so I'd consider it
> >> > worth it.
> >>
> >> Whatever you think is best.  I got lost trying to figure out how
> >> configure did it's thing & ended up putting the define of NI_MAXSERV
> >> in jbsockets.c
> >
> > configure has no magic to satisfy the requirement for a
> > NI_MAXSERV definition in jbsockets.c if IPv6 is disabled.
> 
> Not that I could follow it, but it sure seems to create header files.

It creates the config.h with various defines through which
other header files are included (or not).

> I was thinking it'd be nice if all the required header files were
> pulled in regardless of IPv6 being enabled or not & leaving out the
> WinXP and later library calls if IPv6 was disabled.

Which header files are required depends on on which features
are enabled. Some of the header files required for IPv6
aren't available on systems without IPv6 support, so they
can't be always included or you'd get compile errors even
if no IPv6-specific functions are called.

For example <winsock2.h> and <ws2tcpip.h> are probably
not available on older Windows versions, so they can't
be always pulled in.

> >> So are you OK with adding
> >>   #ifndef NI_MAXSERV
> >>   #define NI_MAXSERV 32
> >>   #endif /* NI_MAXSERV is undefined */
> >> to jbsockets.c  ... at least as a short-term work-around?
> >
> > Yes.
> 
> OK - I'll put up an IPv4 only version of Privoxy on SF with just that
> change in it

Thanks.

Fabian

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

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

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

iEYEARECAAYFAk7+KO0ACgkQSMVSH78upWN0MwCfUYkDavlHUBBuSzosJoobB695
mr0An2PgZYlPuRxfE0e/XTtmrfKBiEFw
=rUtg
-----END PGP SIGNATURE-----