400 Bad Request after upgrade, when using Server URL
I've upgraded from 2017.1.5 to 2018.1. Everything has gone fine, except that the upgraded version won't work on the server URL it was upgraded on. Instead, it returns an HTTP 400.
Before: TC worked on example.hostname.internal.tld
After: TC fails when server URL is set to example.hostname.internal.tld.
After: TC will work on any other server URL - such as example2.hostname.internal.tld, example.other-hostname.internal.tld, etc
I cannot find anything related in teamcity-server.log. The entire response when using the original hostname looks like:
HTTP/1.1 400
Transfer-Encoding: chunked
Date: Mon, 10 Sep 2018 15:35:06 GMT
Connection: close
Obviously we could migrate to a new hostname, but we'd rather not, due to integrations depending on the original one, build agents, etc.
How can we troubleshoot this? Thanks!
Please sign in to leave a comment.
Hi Andrew,
I'd like to confirm something first. You mention "Server URL". We have a setting in TeamCity, called Server URL, used in several features through the product. I'm understanding you do *not* mean that setting, correct? I understand that you are setting it through the host name, be it directly on the host or via dns or proxy?
A bad request response (HTTP 400) isn't always registered within TeamCity. If it's blocked by tomcat prior, it might be registered into the catalina.out or some of the non-teamcity log files, so you might want to check those as well. If you have proxies, reverse proxies, etc, you might want to ensure they are properly set up, or check their logs as well. If you have modified the server.xml file from tomcat to run TeamCity, you might want to double check it as well.
Hey Denis - that's actually correct, I'm referring to the "Server URL" field in the Teamcity backend, not any load balancer/proxy/etc. This is the only field that I change to see this problem.
We're running TC on Windows; I can't see any catalina.out file in c:\teamcity\logs - in fact, the only catalina file I have is datestamped on server startup (i.e. yesterday). I also can't see any other logfiles which are timestamped at relevant times. Is there a log level I can change to see these kinds of events?
Some additional detail:
I have checked that the "bad" hostname resolves to the correct IP address
I have checked that the "bad" hostname exhibits the same behaviour for anyone within our organisation - it's not just my computer
I have checked that TC is still accessible on the machine's network hostname and the machine's IP address too - it's running fine.
The only time I get an HTTP 400 is when using the magic hostname. Very very weird.
Hi Andrew,
thanks for the clarification. That's pretty strange, as that value is used for multiple internal tasks, but shouldn't have an effect on that. Also the catalina.out file should be generated, but if the previous days have also had the issue, they should contain information about it.
I'd like to suggest checking any proxy/reverse proxy or firewalls you might have in between. I understand that it only happens when changing that setting on the server, but if the proxy is redirecting requests incorrectly, that might end up with the result. The error 400 seems to be very specific. If the server url is set up to be incorrect, nothing happens, the server works just fine. You might also want to check the server.xml file to check that you don't have anything wrongly configured there.
I am also seeing this issue, has there been a resolution?
I can access the web ui via the servers ip address but not the host name. I can also access via localhost on the machine as well.
Everything worked in the previous installation.
I see this in the catalina log:
[http-nio-8080-exec-1] org.apache.coyote.AbstractProcessor.parseHost The host [eng_cont_build:8080] is not valid
eng_cont_build is the machine host name.
Ok, After some research it appears that "_" in host name are now considered invalid by the HttpParser