Setting HTTP status code using DCL CGI script under CSWS?

[Duane Sadowski]

Hi. I'm new to CGI programming. I'm writing DCL CGI code in a CSWS V1.3-1 Web server environment, and I'm writing with a question about DCL CGI programming. Can someone please tell me whether it's possible within a DCL CGI command procedure to assign an HTTP status code to override the normal "200 OK" code?

The book "CGI Programming with Perl" says that there's a special "Status" header that "specifies the status code the server should include in the status line of the request", and proceeds to show an example how to do this in Perl. I'd like to do the same thing in DCL. I'd like to set an HTTP status code when my code can't produce the output the user seeks, for example, if the user specified a record identifier using an invalid format for the identifier.

I tried modifying a simple DCL CGI command procedure from the "Writing Real Programs in DCL" book, adding the following line within the section of code that prints the "Content-type" header:

$ display "status: 503 Resource Unavailable"

("display" is a symbol with the value "write sys$output".)

Unfortunately, the Web server seemed to ignore this command. It didn't make a difference whether I put this line before or after the line that prints the "Content-type" header.

I looked in the Web server's ACCESS_LOG file to try to get insight into this, but my attempts to run the script didn't appear to be logged.

FWIW, the system running the Web server is running OpenVMS Alpha 7.3-2.

- Duane

[Wim Van den Wyngaert]

This is an example I found in WASD.

Wim

[Wim Van den Wyngaert]

And another one using sys$output.

Wim

[Duane Sadowski]

Wim:

Thanks for the code samples. These seem to confirm that one can do this in a VMS / DCL environment.

The big question that remains is whether release 1.3-1 of the HP Secure Web server / CSWS, the Web server that I'm using, supports the "Status" header feature.

- Duane

[Robert Atkinson]

Duane,
it doesn't really matter what the web server is your running (as long as you get the syntax right). Whatever you send as the header will simply be sent to the browser.

Sending 'custom' headers is normally done for file-attachments, i.e.

$ CONTENT_HEADER = "Content-Disposition: attachment; filename=''FILENAME'"
$ WS F$FAO("''CONTENT_FAO'","Content-type: ''MIMESTRING'",CONTENT_HEADER)

As long as you get the syntax right, which should be "Status: xxx" then it should work. You just need to be carefull that Apache expects the header to be sent in a very particular way formatted with F$FAO.

Robert.

[Sebastian Bazley]

Surely the status is derived from the initial line returned by the server, e.g.

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Wed, 14 Dec 2005 18:49:57 GMT
Connection: close
Content-Length: 39

here is the content...

[Steven Schweda]

I'm with Mr. Bazley. You can certainly
produce page content which _says_ "Status:
xxx", but that differs from the server
declaring (and logging) an error "xxx".

You _could_ use an exploding CGI program. If
it dies unexpectedly, the server should
declare some kind of error, but, again,
that's something different.

I suspect that you really want to produce
error pages to show to the victim, not create
actual errors at the server.

[Robert Atkinson]

The point is that you can control the HTTP header in the way described.

Sending this string will give you a valid HTTP error within the browser :-

$ ws "Content-Type: text/plain"
$ ws "Status: 403 Nice try!"

----------

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

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

----------

As you can see, the output is not completely correct. Apache doesn't like it if you don't close the header properly with a CRLF.

Unfortunately, if you do, the browser ignores the status code and just assumes it's been sent a valid page.

I'm still continuing to investigate how to get the correct output.

Rob.

[Sebastian Bazley]

But what happens in this case if the "browser" is a Java program or Perl script or whatever?

Will the client see error 403 or 500?

[Robert Atkinson]

If I can get it working properly, it'll see :-

Content-Type: text/plain CRLF
Status: 403 Nice try! CRLF
CRLF

....which is a valid HTTP header. It's just that last CRLF that's stuffing me at the moment.

Rob.

[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.