[prev in list] [next in list] [prev in thread] [next in thread] 

List:       privoxy-developers
Subject:    [privoxy-devel] [ ijbswa-Feature Requests-732136 ] Use regexp for
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2007-04-16 11:37:12
Message-ID: E1HdPWC-0006V7-Jq () sc8-sf-web24 ! sourceforge ! net
[Download RAW message or body]

Feature Requests item #732136, was opened at 2003-05-04 11:08
Message generated for change (Comment added) made by fabiankeil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=361118&aid=732136&group_id=11118

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: funct: blocking
Group: version 3.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fabian Keil (fabiankeil)
Summary: Use regexp for whole URL

Initial Comment:
The syntax for blocking hosts/paths isn't proper
regular expressions. This is really confusing. It seems
to work like this:

If the expression starts with a &quot;/&quot; then it is matched
as a front-anchored regular expression on the path part
of the url.

If it doesn't start with a &quot;/&quot; then it is interpreted
as a glob (wildcard) expression (&quot;*&quot; is recognised, but
not &quot;?&quot; it seems!?) on the host part of the url,
possibly followed by a regexp on the path part.

If the (host) expression starts with a &quot;.&quot; then the
glob is not front-anchored (ie. it will match any host
in that domain). It it starts with any other character,
it IS front-anchored (it matches only that host). The
same is the case for trailing &quot;.&quot;

So: Why not just make it a proper regexp, matching on
the whole url? Preferably not anchored, just use the
standard regexp anchors (&quot;^$&quot;). It would certainly be
easier to understand.

-- 
cjhaga@ifi.uio.no

----------------------------------------------------------------------

>Comment By: Fabian Keil (fabiankeil)
Date: 2007-04-16 11:37

Message:
Logged In: YES 
user_id=875547
Originator: NO

Dividing the URL pattern into multiple sub patterns
(host, port, path) that are interpreted differently
may confuse beginners who didn't read the user manual,
but it also makes it harder to write incorrect patterns
and makes the patterns easier to read.

For example you don't have to add "(:80)?" every time,
just to make sure you don't miss "www.example.org:80/foo"
URLs, and you don't have to start every pattern with
"^[^/]*", just to make sure the "host" isn't detected inside
the path.

Anyway, with the recently added client-header-tagger
multi action you can tag the request with its URL and than
use full regular expressions to look for the tag later on.

If you wanted you could move all your patterns (except
for the ones for the client-header taggers themselves)
from URL patterns to Tag patterns that look for the whole
URL.

The disadvantages mentioned above would still apply,
so I suggest you only do it in situations were
you really need it. I don't think there are that many.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-07-13 04:23

Message:
Logged In: NO 

Definitely annoying to have separate rules for host and
path. Make it all just one regexp with ^ and $ *vote*


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=361118&aid=732136&group_id=11118

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Ijbswa-developers mailing list
Ijbswa-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ijbswa-developers
[prev in list] [next in list] [prev in thread] [next in thread]