I think it doesn't have to be the 403 page that Apache would have sent, it may just be one you made yourself, and which somewhat looks like a 403 error page.

Besides, as error pages can always be customized, there's no need for it to ever be the real 403 page.

I had read the other thread, but didn't follow everything, given my knowledge level...

So if the header contains the 403 code, then a bot might hopefully interpret that correctly and go away (hopefully!)?

BTW, There are certain types of data errors that I want to reply with this fake reply, while for other 'normal' errors, I have a nice formatted page that I use, so determining which to send needs to occur within my CGI script, as I see it.

I'm also presuming that I could output a minimal "Access Forbidden" page with this response code, so a browser user would see that?
As the standard config error page (I believe) gives an email addr, which I don't want to provide in this case.

So if the header contains the 403 code, then a bot might hopefully interpret that correctly and go away (hopefully!)?

One would think so, but at the very least you're not wasting bandwidth sending real content.

grep

1)Gain XP 2)??? 3)Profit

What I'm trying to do is create an error reply to a POST request from a spam bot, or actual browser user who makes certain fatal errors.

From RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.4 403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

So, status 403 is just a hint to the client, and passing any meaningful information is up to you.

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

And, to confuse things further -- you need to send a large enough response. (MS knowledgebase #294807 ... which I'd link to, but they'll make you authenticate and such)

Internet Explorer 5 and after will display a 'friendly' error message, which basically ignores the message sent, and just keys off of the error code -- if the message body is less than 512 bytes.

So, make sure that your error messages are large enough, so that they actually get displayed.

THANKS to all who have so kindly replied!

I've ended up with the following, which shows fine in IE 6, even though it's somewhat short:



use CGI;
$query = CGI::new();
print $query->header(-type=>'text/html',
                     -status=>'403 Forbidden');
print $query->start_html('Acesss Forbidden!');
print $query->h1('Access Forbidden!');
print $query->p("Access to this resource is forbidden.");
print $query->h2('Error 403');
print $query->end_html();
[download]



As I have NO idea of exactly where to find default one from Apache on my host, and I may not have access to it via FTP anyway, so this will have to do...

So, make sure that your error messages are large enough, so that they actually get displayed.
No.

You can have the error page be a CGI script, but the actual hookup is an Apache config.

That would normally be the correct answer, but the OP is "faking" a 403, not dealing with real 403's. From what I understand, the OP is using an existing script and throwing a 403 based on input. So unless the script is always called by a real 403 then this would not work (well).

grep

1)Gain XP 2)??? 3)Profit