One of our RedHat servers decided it wasn't going to play ball this morning (worthy of another email on exactly this subject actually) but as an upshot of this, I've had to move several websites to another server that is being good.
So...
ftp'ed the websites to the other server and cut-n-pasted the apache config file etc. After fidding around a bit have managed to get everything up and running -except- for two virtual domains which aren't behaving themselves. As it happens, these two domains are on both 80 and 443 (SSL). When I access them, I get an HTTP 302 which I don't really understand. All the other domains are working fine. Have examined the logs and used telnet to connect to port 80 to see exactly what headers etc are coming back. Normally, a 302 should give a URL to redirect to, which in this case is "http://" without any other info. Weird.
Any ideas/clues - am getting very frustrated now?
Cheers.
Mark W.
PS. apache 1.3.14 w mod_ssl 2.5.1 and mod_php4.0.4pl1
Mark Wilkinson wrote:
One of our RedHat servers decided it wasn't going to play ball this morning (worthy of another email on exactly this subject actually) but as an upshot of this, I've had to move several websites to another server that is being good.
So...
ftp'ed the websites to the other server and cut-n-pasted the apache config file etc. After fidding around a bit have managed to get everything up and running -except- for two virtual domains which aren't behaving themselves. As it happens, these two domains are on both 80 and 443 (SSL). When I access them, I get an HTTP 302 which I don't really understand.
302 is a "moved temporarily" code... I would have another look (or get somebody else to look) at the config file if I were you....
Sz
All the other domains are working fine. Have examined the logs and used telnet to connect to port 80 to see exactly what headers etc are coming back. Normally, a 302 should give a URL to redirect to, which in this case is "http://" without any other info. Weird.
Any ideas/clues - am getting very frustrated now?
Cheers.
Mark W.
PS. apache 1.3.14 w mod_ssl 2.5.1 and mod_php4.0.4pl1
alug, the Anglian Linux User Group list Send list replies to alug@stu.uea.ac.uk http://rabbit.stu.uea.ac.uk/cgi-bin/listinfo/alug See the website for instructions on digest or unsub!
For everyone's info on this one... I got my co-worker to try these sites on his connection at home and they work fine. NTL must be doing some transparent-proxy stuff that's causing problems.
Cheers.
Mark W.
-----Original Message----- From: Neill Newman [mailto:neill@entora.co.uk] Sent: 21 April 2001 16:23 To: mark@wilkinson.uk.com Cc: alug@stu.uea.ac.uk Subject: Re: [Alug] Desperate Apache Problem!
Mark Wilkinson wrote:
One of our RedHat servers decided it wasn't going to play ball
this morning
(worthy of another email on exactly this subject actually) but
as an upshot
of this, I've had to move several websites to another server
that is being
good.
So...
ftp'ed the websites to the other server and cut-n-pasted the
apache config
file etc. After fidding around a bit have managed to get
everything up and
running -except- for two virtual domains which aren't behaving
themselves.
As it happens, these two domains are on both 80 and 443 (SSL).
When I access
them, I get an HTTP 302 which I don't really understand.
302 is a "moved temporarily" code... I would have another look (or get somebody else to look) at the config file if I were you....
Sz
All the other domains are working fine. Have examined the logs and used
telnet to connect
to port 80 to see exactly what headers etc are coming back.
Normally, a 302
should give a URL to redirect to, which in this case is
"http://" without
any other info. Weird.
Any ideas/clues - am getting very frustrated now?
Cheers.
Mark W.
PS. apache 1.3.14 w mod_ssl 2.5.1 and mod_php4.0.4pl1
alug, the Anglian Linux User Group list Send list replies to alug@stu.uea.ac.uk http://rabbit.stu.uea.ac.uk/cgi-bin/listinfo/alug See the website for instructions on digest or unsub!
-- Open source solutions at http://www.entora.co.uk/
Mark Wilkinson wrote:
For everyone's info on this one... I got my co-worker to try these sites on his connection at home and they work fine. NTL must be doing some transparent-proxy stuff that's causing problems.
NTL are always causing problems :-) try telnetting directly to the webserver on port 80 and typing (if the syntax is wrong someone can correct me) HEAD / HTTP/1.0
If you see a line referring to Inktomi traffic server then NTL have got you! anyway you should see something referring to the traffic servers as NTL have them all over their network I think.
Adam
Adam Bower wrote:
NTL are always causing problems :-)
tell me about it...
try telnetting directly to the webserver on port 80 and typing (if the syntax is wrong someone can correct me) HEAD / HTTP/1.0
yup it's the right syntax, it's also a usefull way of discovering all kinds of usefull info about a machine, of course queos/nessus helps as well ;)