'[privoxy-devel] [ ijbswa-Feature Requests-1000730 ] forward-only'

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

List:       privoxy-developers
Subject:    [privoxy-devel] [ ijbswa-Feature Requests-1000730 ] forward-only
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2007-04-23 15:31:38
Message-ID: E1Hg0Vu-0003QG-4B () sc8-sf-web22 ! sourceforge ! net
[Download RAW message or body]

Feature Requests item #1000730, was opened at 2004-07-30 14:27
Message generated for change (Comment added) made by fabiankeil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=361118&aid=1000730&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Michael T. Davis (davis157)
Assigned to: Fabian Keil (fabiankeil)
Summary: forward-only option

Initial Comment:
This request is similar in nature to...

http://sourceforge.net/tracker/?
group_id=11118&atid=361118&func=detail&aid=668386

Rather than remote access to a chained privoxy, I'd just 
like to be able to _only_ forward data. What I had in 
mind was another type of ACL entry. Besides allow-
access and deny-access, how about a forward-only 
option? This would work similarly to allow-access, but it 
would flag any requests not to go through 
blocking/filtering. This is especially handy when you 
come across a site for which a newly-developed filter 
rule fails to the point that privoxy crashes. If the remote 
privoxy crashes, you can't continue on unless you have 
some mechanism in place to access the remote system 
(e.g. VNC) and restart privoxy there. On the other hand, 
if the remote privoxy isn't performing any 
blocking/filtering, you only have the local instance of 
privoxy to worry about. This also can save on 
resources, in that you wouldn't need to implement a pr
(iv)oxy system just to handle simple proxying chores for 
a remote privoxy system.

Regards,
Mike

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

>Comment By: Fabian Keil (fabiankeil)
Date: 2007-04-23 15:31

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

With the recently added tags you can enable
and disable actions based on the headers.

As a result you can invent your own version
of "X-Filter", so I think this request can
be closed.


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

Comment By: Fabian Keil (fabiankeil)
Date: 2006-09-24 16:24

Message:
Logged In: YES 
user_id=875547

You are right, "X-Filter: No" only affects filtering.
Similar headers are already planned.

In your case, the local Privoxy version could
additionally add "PRIVOXY-FORCE/" to all
URL it fetches through the remote Privoxy, though.

I misunderstood what you requested and now recognise
that just removing all action files isn't acceptable in
your case. I'm reclassifying this request as "Accepted",
it may take a while though.

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

Comment By: Michael T. Davis (davis157)
Date: 2006-09-24 15:51

Message:
Logged In: YES 
user_id=467222

If the X-Filter header name is really indicative of what 
it controls, it would only apply to filtering, but not the 
application of actions by the remote system on the 
forwarded data. Since filters are called upon by action 
rules, it would be worthwhile to provide a second option 
controlled by such a header, such as X-Apply-actions, or 
something like that. As such, X-Filter would control only 
filtering, and X-Apply-actions would basically handle 
everything (i.e. actions and filters, implicitly).

Regards,
Mike

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

Comment By: Fabian Keil (fabiankeil)
Date: 2006-09-24 15:37

Message:
Logged In: YES 
user_id=875547

With Privoxy 3.0.5 beta you can have the local Privoxy
set the "X-Filter: No" header.

It causes the remote Privoxy to disable filtering for these
requests only, no matter how the action files looks like.

Does this solves your problem?

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

Comment By: Michael T. Davis (davis157)
Date: 2006-09-24 14:57

Message:
Logged In: YES 
user_id=467222

So I have a chained configuration, whereby one Privoxy 
instance ("local") forwards to another ("remote"). This 
allows me to access sites that are restricted to the IP 
address range(s) that include the system where the remote 
instance runs. In terms of actions/filters, the 
configurations are identical. I don't want to have to 
manually disable the actions/filters on the remote system 
when I'm using the local system -- I just want to blindly 
forward to the remote system via Privoxy, without the 
actions/filters on the remote side getting in the way. 
(The local actions/filter set should be the only ones that 
apply when I'm using the local system.) I could run a 
simple (second) proxy on the remote system, but I'd rather 
minimize the resources consumed by only using a single 
proxy (i.e. Privoxy).  (Privoxy provides the underlying 
functionality, so why "re-invent [or re-implement] the 
wheel"?)

Note that rebuilding from source is not an option for the 
typical end-user. I can already access the remote 
configuration via (SSH-protected) VNC or I could even set 
up the Web-based configuration access. Either of these 
mechanisms, though, calls for me to manually switch the 
actions/filters on/off, which is what I want to avoid.

Regards,
Mike

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

Comment By: Fabian Keil (fabiankeil)
Date: 2006-09-24 13:58

Message:
Logged In: YES 
user_id=875547

If you don't use any action files Privoxy basically
becomes a forward only proxy. I don't see the need
for a special config option here?

If you want to acces the configuration of chained
Privoxys, you just have to change CGI_SITE_2_HOST
in project.h. I'm planning to turn it into a config
option as well.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=361118&aid=1000730&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]
Configure | About | News | Add a list | Sponsored by KoreLogic