in reply to testing http server

In my experience, these two things are two tests among hundreds ... and, since they mostly have to do with proper Apache or nginix configuration, they might not need to be part of your internal testing at all.   What you are really most interested in, is that the responses (however requested and received) are correct.

I have had most success using Selenium, driven on the client side by Perl scripts.   This tool drives an actual browser, through a remote-control interface, and does it from the client side.   Interfaces to whatever programming tools might be available on the testing-client (specifically including Perl) are plentiful, so the two computers can work together (in your testing lab) however you best see fit.

Obviously, while developers are writing the code, Mechanize-style tests are very convenient “also,” and once again I would not prioritize the HTTP 401/403/302 tests unnecessarily when writing them.   I might not include them at all.   The configuration of a testing machine, known to be inside the network etc., can legitimately be simpler than the big hairy outside-world would be.   You simply want to automate the presenting of inputs to the thing and the evaluation of responses received.

Replies are listed 'Best First'.
Re^2: testing http server
by fisher (Priest) on Jan 15, 2013 at 16:52 UTC

    since they mostly have to do with proper Apache or nginix configuration,

    your assumption is wrong here. I have to deal with multiple instances of this web-server and noone can guarantee the configuration is proper. I want to check this configuration, the availability of common handlers, the closed doors to some insider's data and proper redirection to some known queries.