On Wednesday 02 January 2002 10:04 am, Tavis Rudd wrote:
> > I agree. Unless someone has an argument for 403 Forbidden, I prefer
> > to just have 404 Not Found.
>
> I'm not sure we gain anything extra by returning a 404 instead of
> 403.  This is essentially security by obscurity, but it's not clear
> what we're trying to obscure.  Anyone familiar with WebKit will know
> that .pyc files exist and that .py~ files probably exist.  What else
> might we be revealing?

Regarding security, I prefer the position "What is the motivation for 
revealing internal details of the system?" If there is no such 
motivation, I don't reveal the detail.

I think that's a safer approach than exposing unnecessary details of a 
system because we can't currently imagine any harm.


> On the other hand, a 404 error in the logs mean something different
> than a 403 error.  Using 404 in this case would obscure what is
> really going on with bogus requests.

True, although I can't say I really mind.


> Apache returns 403 for a .htaccess, .htpasswd, etc. so I prefer it to
> 404. In fact, it returns 403 even if those files don't exist. The
> WebKit stuff is all happening after the webserver's initial request
> processing so those who do want a 404 message can still use
> mod_rewrite to get one.

I find it obscure that Apache would 403 a non-existant file since it 
would lead me to believe it was there (perhaps I'm poking around as an 
admin).


In any case, should we have FilesToForbid and FilesToNotFind? That way 
the names match the response and you can do as you like. Or we could 
have something more generic that lets you specify the status code and 
string, perhaps even multiple groups.

Thoughts?



Additionally, I would like to deny the use of extensions for my site 
for various reasons:
  - it's unnecessary
  - some of my servlet code (in SitePage) parses the URL and I don't 
want to have to test the site with and without extensions
  - if the user bookmarks such a URL, it could break later when I 
switch techniques

I haven't thought about where to put that in the process.


-Chuck

_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss

Reply via email to