How to make "Server Name" ban work in Extended Networking

[ahkow]

Hi, first of all, I am not using the Wingate Proxy. So I put my ban list in Extended Networking.
I open properties for Everyone under Policies of Extended Networking.
Then I add '"Server name contains "youtube"' in Ban List.
But it never works.
If I put "Server IP equals ....", it works.
What does "Server name" do actually? Is it the same as "HTTP URL" ?
And why doesn't the Ban List of Extended Networking have 'HTTP URL' ??

My version is 6.2.1 Build 1133
Thanks.

[Nev]

And why doesn't the Ban List of Extended Networking have 'HTTP URL' ??

Hi, well basically NAT does not resolve to name so it's numerical addresses or nothing for your filter.

Not an ideal work around but you can enable intercepts and apply name policies in the WWW proxy for the result you want.

[ChrisH]

Hi, the server name is that part of the URL that is after the http:// (protocol) and up to and including the top level domain (.com ,.net ,etc). The URL includes that and any other path to resources on the web server. So, on this forum, server name = forums.qbik.com and URL includes viewtopic.php. Having said this I can set up a policy under extended networking, ban list, where server name contains youtube and the results are as expected. I noticed you indicated "" around youtube in your posting. Was that just for the post or did you actually include the quotation marks in your policy? They shouldn't be there if you did.

[ahkow]

Thanks,

The quotation marks are for the post only :)
The WWW Proxy intercept works. I intercept port 80 and ban HTTP URL which contains 'youtube'.
But why isn't it an ideal workaround ?

Thanks again.

[logan]

It's not that intercepting isn't an ideal workaround. For convenience sake, intercepting is very ideal, but it works outside the boundaries of what's defined by RFC. Simply put, HTTP was not designed to be intercepted, so you may or may not experience some problems while using intercepts.

If you aren't doing anything terribly advanced with your WWW proxy, just blacklisting url's, then intercepting port 80 is great and shouldn't give you much problem at all.

[Nev]

If you aren't doing anything terribly advanced with your WWW proxy, just blacklisting url's, then intercepting port 80 is great and shouldn't give you much problem at all.

Hi Logan,

Intercepting is all ok as long as the client user isn't using SeaMonkey [maybe FF too] and seeking a direct connection.

If there is caching involved, the last time I tried this web pages soon went way out of shape, maybe it's cured now, Adrien was looking at it.

IE is ok then that's another area all together.

:)

[logan]

Ah SeaMonkey, part of the '1 percent of other' group of browsers :D. I haven't noticed any problems like that re: caching and FF, but I think SeaMonkey was based on the full on Mozilla browser, instead of the fox.

In the case where users might be using SeaMonkey, combining intercepts plus manually configured clients is probably the best solution. Configure the Sea Monkey clients to use the proxy manually, but have the intercept enabled so that all the IE/FF computers don't need to do this, and the SeaMonkey users that try to disable the proxy setting just end up shooting themselves in the foot. What's the admin gonna say when he has to fix the computer and finds the proxy setting was disabled :D.