The Un-Official Proxomitron Forum

Hi all,

I imported my filters (prox 4.5) then made a new config using only my filters. I noticed right away I was having web & header filter issues. To start troubleshooting, on the setup screen I disabled my web filters so I could concentrate on fixing my header filters.

First off, with the log window open, I noticed alot of header filters seemed to be matching when the header didn't exist.

For example this filter was matching (proxomitron code):

Code:

In = TRUE

Out = FALSE

Key = "Last-Modified: 1. Use our Cache Controls (In)"

Match = "*"

To correct this, I modifed the the proximodo code as follows:

Code:

Match = ?*

Not a big deal, its just different. After modifying all the other header filters that had a similar match expression, things looked much better.

I then noticed that my caching header filter wasn't working. In Proxomitron, I use two header filters like so:

Code:

In = TRUE

Out = FALSE

Key = "Cache-Control: 1. Use our Cache Controls (in)"

Match = "*"

In = TRUE

Out = FALSE

Key = "Cache-Control: 2. Cache all but Html (in)"

Match = "^$IHDR(content-type: *(html|xml))"

Replace = "max-age=28800"

In Proxomitron, the first filter deletes a Cache-Control header if one is present. The second filter adds the Header back in if the Content-Type header indicates that the response is not html code.

After trying several variations of this, I cannot get this to work.

Filter #1 would match twice, so I added $STOP() at the end of the matchinig expression for Filter #1. After that, Filter #1 only matched once, but filter #2 never matched.

I then disabled Filter #1 and found Filter #2 always matched. After playing around with it for a while, I found that Filter #2 either always matched, or never matched, depending on the matching expression I used.

I have concluded the following:

Using the $Stop() command in a header disables other filters that match the same header, not just that filter.

The commands $IHDR() and $OHDR() don't work in header filters.

Maybe I'm missing the obvious solution. Can someone see if they can make my caching filters work?

Mike

Okay, I'll fix it right now Smile!

Wow, that was quick. Thanks for looking into it. Smile!

By the way, I'm not certain that my conclusions were correct. Wink

Mike

I made two changes:
- implemented the ^ notation at beginning of pattern (there was only (^...) up to now)
- a header filter which pattern is * or \digit will not match a blank header
That should make your caching filters work.

About your $stop question, weren't there 2 "cache-control" headers in the request? That would have been the only possibility I know for having the same filter run twice. Filters are completely independant and $stop only acts on the filter it is in.

Anyway, in my new code, multiple-defined headers are concanated (wrt. HTTP standard) and header filters are run _only once_ on their corresponding headers, in configuration order. So $stop work in header filters but is useless (filters are reenabled on next request). If this is not the expected behavior, let me know.

Antony

Hi Antony

Antony Wrote:I made two changes:
- implemented the ^ notation at beginning of pattern (there was only (^...) up to now)
- a header filter which pattern is * or \digit will not match a blank header

The changes in your new code seem right to me. I have seen alot of filters that use both of those methods.

With respect to the "cache-control" header, it doesn't seem to be a very common reply header. Yet each reply showed 2 matches for it, due to my filters I suspect. I am going to fix my "content-type" filter, that I mentioned in the other post then fire up Proximodo again. I'll also revisit the "cache-control" filters to more closely examine what is going on. If I see the same header filter match more than once in the same reply, I'll copy a portion of the log window and post it back here.

As for $STOP, I used $STOP only as a last resort. Since this is not Proximitron, I am trying to not make the assumption that it must work like it in every respect. I am however, trying to learn how to handle any differences that may exist.

Antony Wrote:Anyway, in my new code, multiple-defined headers are concanated (wrt. HTTP standard) and header filters are run _only once_ on their corresponding headers, in configuration order.

Now thats a bit different than Proxomitron. I especially like the "in configuration order" portion of that. Smile!

Proxomitron has a limited ability to do this with regards to ordering the header filters.

Keep up the good work
Mike

More precisely, I am currently adding a "priority" field to the filters.
Text filters will run in decreasing order of priority, and headers filters too will run in decreasing order of priority.
The difference with v0.1 is that you can add/remove filters to a config without worrying about their order anymore, that order is a property of filters. Much better for interdependent filters: when you import them from Proxomitron, they are not shuffled anymore ;-)

That will be the first step towards the tree-like filter set, where filter packs can be placed in distinct folders (you'll love it).

z12

kuruden

z12

kuruden

z12

kuruden