From: Fabian K. <fk...@fa...> - 2011-12-29 19:56:19
|
Lee <le...@gm...> wrote: > On 12/28/11, Fabian Keil <fk...@fa...> wrote: > > Lee <le...@gm...> wrote: > > > >> On 12/28/11, Fabian Keil <fk...@fa...> wrote: > >> > Lee <le...@gm...> wrote: > >> > > >> >> On 12/27/11, Fabian Keil <fk...@fa...> wrote: > >> >> > Lee <le...@gm...> 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 |