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.