trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Smith <>
Subject RE: Odd 302 behavior
Date Thu, 24 Apr 2014 22:16:14 GMT
So, changing that pristine_host_hdr variable worked.  Can someone explain why?
Also, I found the suggestions about debug, etc to be very helpful in troubleshooting a couple
of things, and getting a good bead on a problem with the app server backend.

Subject: Re: Odd 302 behavior
Date: Thu, 24 Apr 2014 14:32:56 +0800

sounds to me you haven’t check the backend server access logs, in your case, if your origin
server may have a default virtual host or similar 302 to the www host, you may get some unexpected
result as you got now.
and please check: 'CONFIG proxy.config.url_remap.pristine_host_hdr INT 1’, you can set to
‘0’ in your case.
anyway, check the input and out put is always a good idea. and https is not easy to debug,
you may change it ti http:// in the mapped to, to get it easy to tcpdump.


- Yongming Zhao 赵永明

在 2014年4月24日,下午12:51,Frank Smith <> 写道:Thanks.
 I will double check that I am using the trailing slash.  Also, appreciate the help with pointing
me at debug tags and http_ui, some additional visibility could be very helpful here - particularly
the raw HTTP headers.
Out of curiosity, when I was debugging, I decided to try to use a known 'good' site as my
HTTPS backend, and I decided to try proxying myself to GitHub's website as a test.  (Since
I don't know whether I trust the configuration of my app server.)
I abandoned that test, because it appeared that GitHub managed to get my browser to redirect
itself to their site, or depending on how I messed with the mappings - error out all together.
Can anyone conceptually explain to me what is happening there, and what the correct way to
do that would be?  
Obviously, I have no interest in reverse_proxying my URL to GitHub, but I thought it might
be an interesting common example we could use to understand how this is supposed to work.
An example or two like that could really help the docs - since it is the proxy equivalent
of being able to use sample code.

Subject: Re: Odd 302 behavior
Date: Thu, 24 Apr 2014 11:51:08 +0800

no idea the root cause.
but here is my points:
1, I’d use the / with hostname in the map: map
that may help reducing some bad situation where ATS may …
2, the last redirect to www looks like a forward proxy behavior?
3, always consider the http_ui & debug tags in records.config, for the cache and http

hopes that will help

- Yongming Zhao 赵永明
在 2014年4月24日,上午10:28,Frank Smith <> 写道:I
am new to the Traffic Server and I could use some help because I have some odd behavior, which
could be my ignorance, or perhaps an issue.
So, I have an HTTPS server we will call reverse proxying to my application, which is also HTTPS.
So, I have my remap.config with:
(and I have tried both with and without this next line)
When I front this through my browsers, both Chrome and IE, I get an error about page not found
or something (these user friendly messages are hard to understand what is happening under
the hood).
When I tail the extended2.log file during my reverse proxy request, I see the GET to
with a 302 status.
However, I can pull up directly online my origin server - through
a web browser with no problem, as we are still testing this configuration - eventually we
will move the behind the proxy server.  I should note that I work on the
proxy team, and don't have much visibility to the app team - any questions I should ask of
them, would be greatly appreciated.
To isolate the problem, I logged into the Traffic server, and issued a wget to the
and I got the exact same response I get in a web browser.
So, then I wget against my gateway server -, and I get it trying
to redirect to www.mydomain.comand not finding that in the DNS, it bombs.  I have no idea
why it is trying to redirect there, and it doesn't try when I make the request directly with
a web browser or wget (on the server).
So, clearly there is a problem there, but I don't know where/how to hunt the problem down...
View raw message