Re: Release date for Privoxy 3.0.19 stable

Lee <[email protected]> wrote:

> On 12/28/11, Fabian Keil <[email protected]> wrote:
> > Lee <[email protected]> wrote:
> >
> >> On 12/28/11, Fabian Keil <[email protected]> wrote:
> >> > Lee <[email protected]> wrote:
> >> >
> >> >> On 12/27/11, Fabian Keil <[email protected]> wrote:
> >> >> > Lee <[email protected]> wrote:
> >> >
> >> >> >> I finally got around to checking email again..  Windows build is up
> >> >> >> on
> >> >> >> SF and, after a bit of poking around, privoxy-setup 3.0.19 is the
> >> >> >> default windows download :)
> >> >> >
> >> >> > Great. I assume you built it with IPv6 support?
> >> >>
> >> >> Yes.  I did the build on a Vista machine using winsetup/GNUmakefile so
> >> >> the configure options were
> >> >>   ./configure --enable-mingw32 --disable-pthread
> >> >> --disable-dynamic-pcre --enable-zlib
> >> >
> >> > It's unfortunate that --disable-dynamic-pcre seems to be
> >> > necessary on Windows, but other than that these look like
> >> > reasonable settings for most users.
> >>
> >> All that's required is "./configure --enable-mingw32".
> >
> > My main concern (which I didn't clearly articulate above) is that
> > the outdated internal pcre version is used. At least a few years
> > ago linking to a more recent version wasn't an option on Windows.
> 
> Ahh..  yes, I missed that.
> 
> 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, 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.
|
| Note that the requirement is to allow the user to decide
| if the domain pattern should be interpreted as regex or
| traditional host pattern and if it's not obvious that the
| user made any decision, default to the latter.
|
| Possible solutions would be:
|
| 1. An always-use-regex-domain-patterns config option
| 2. An enable-regex-domain-patterns-for-this-action-file option
| 3. An enable-regex-domain-patterns-for-this-action-file-until-the-user-says-otherwise option
| 4. A treat-the-domain-pattern-in-this-line-as-regex(-or-not) option
| 5. Combinations of the options above
|
| With 2+4, 3+4 or 2+3+4 being the preferences until
| further discussion.

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

It just happens to work by accident on most platforms other
than Windows as <netdb.h> in included unconditionally there.

> diff -U4 /cvs/privoxy/current/jbsockets.c current/jbsockets.c
> --- /cvs/privoxy/current/jbsockets.c    2011-12-18 17:00:39.731285800 -0500
> +++ current/jbsockets.c 2011-12-28 23:53:48.007010200 -0500
> @@ -961,8 +961,16 @@
>  #endif /* def HAVE_GETHOSTBYADDR_R_(8|7|5)_ARGS */
>  #endif /* ifndef HAVE_RFC2553 */
>     s_length = s_length_provided = sizeof(server);
> 
> +
> +/* work-around for "./configure --enable-mingw32 --disable-ipv6-support" not
> + * pulling in whatever it is that defines NI_MAXSERV
> + */
> +#ifndef NI_MAXSERV
> +#define NI_MAXSERV 32
> +#endif /* NI_MAXSERV is undefined */
> +
>     if (NULL != hostname)
>     {
>        *hostname = NULL;
>     }
> 
> 
> That works, http://config.privoxy.org/show-status says
> FEATURE_IPV6_SUPPORT 	No 	Allows IPv6 addresses in incoming requests,
> when resolving domains to IP addresses and in the configuration files.
> 
> and ws2_32 is not pulled in as a library:

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

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)

iEYEARECAAYFAk78xbcACgkQSMVSH78upWND4ACeLTOT3E0lU1djI/ceP11WTwJN
csoAoIoqJpBpPBB2mOPGCrAW2ta1cs12
=+t83
-----END PGP SIGNATURE-----