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.
Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
Want more info? How to link or
or How to display code and escape characters
are good places to start.