Setting HTTP status code using DCL CGI script under CSWS?

[Duane Sadowski]

Robert, Sebastian, Steven:

Thanks for the additional information.

I think that I made a beginner's conceptual mistake, and I think that was part of the difficulty that I experienced.

I was initially assuming that if I'm using a Web browser such as Firefox, the browser reacts in an explicit manner to an error status returned by the server in the top line of the server's response, but now I doubt that assumption. I now assume that the browser merely displays the content that follows the HTTP header returned by the server, which in the case of a non-200 status would typically be an HTML document with some error message in the body of the document. So when I concluded that my DCL command procedure wasn't working, I think I might have been mistaken.

To see what status code the server is sending back to the browser, I think I should not be relying on what I see in the Web browser window. (Sebastian Bazley wrote about the possibility that some program other than a conventional Web browser might access the Web server, and indeed that's the type of "browser" with which I need to be concerned.)

To test my DCL CGI, I think I should instead be doing one of two things: either looking at the entries in the Secure Web Server's log files, or else TELNETing to the Web server, issuing a GET command to launch the DCL CGI, and watching what the server sends back. (A problem that I encounter looking at the log file entries is that it appears that I have to wait many hours before they're visible to me in the log files.)

- Duane

[Steven Schweda]

You may find a program like Wget more
convenient than Telnet for your non-browser
HTTP GET activity.
(http://antinode.org/dec/sw/wget.html)

I flush my CSWS logs files by doing a RESTART
every hour (or so) with a self-resubmitting
batch job. (There was a problem with FLUSH.)

You can also have your CGI program write data
to its own diagnostic file(s). You won't
need to wait for that.

[Duane Sadowski]

Steven:

Thanks for the reference to wget, for explaining how to view the log file entries more readily, and for suggesting a separate file containing diagnostic information.

- Duane

[Steven Schweda]

Sorry about the 404 errors caused by the
mangled URL in the "helpful" ITRC Forum
interpretation. Apparently, many forms of
quotation cause trouble. This should be clean:

http://antinode.org/dec/sw/wget.html

(It sure would be nice if the Forum-formed
links were just plain links instead of all
the JavaJive.)

[Duane Sadowski]

Steven:

Thanks for the clarification of the URL. At first, I thought it was an obsolete link, but I eventually figured out that the problem was the closing parenthesis within the URL.

- Duane

[Robert Atkinson]

Duane,
your first assumption was correct regarding the interpretation of the status code.

As with my example, this text is returned :-

Nice try!
You don't have permission to access /cms-cgi/ht_test on this server.


As you can see, although I sent the 'Nice Try' message, IE interpretted the status code and also outputted "You don't have permission to access /cms-cgi/ht_test on this server."

As you've said though, I wouldn't rely on the browser giving you the information you require, especially IE which loves to wrap errors in cute little messages.

Rob.

[Duane Sadowski]

Rob:

Thanks for confirming my understanding.

> Nice try!
> You don't have permission to access
> /cms-cgi/ht_test on this server.

Could you please clarify one thing? The first phrase, "Nice try!", is clearly coming from your program, but what about the second phrase, "You don't have permission...
"? Are you generating that with a WS command in your DCL command procedure, or is the Web server generating that phrase as a consequence of the 403 code and sending it to the browser, or is the Web browser generating that in response to the 403 code? (I think that the answer is that the browser is doing this, but I want to make sure I understand things correctly.)

- Duane

[Robert Atkinson]

You're correct. The Browser is generating the message, which is it's interpretation of a '403' error.

Rob.

[Duane Sadowski]

Thanks again for the help. As things turned out, the outside developer with whom we worked on this ended up having us specify code numbers within the body of the document instead of using HTTP codes.