[ https://issues.apache.org/jira/browse/TS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-309: ----------------------------- Fix Version/s: (was: 3.1.2) 3.2.0 > Report OS Errors in Header > -------------------------- > > Key: TS-309 > URL: https://issues.apache.org/jira/browse/TS-309 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP > Reporter: Miles Libbey > Fix For: 3.2.0 > > > (from yahoo bug 1021194) > Original description > by Ryan Troll 3 years ago at 2007-01-17 13:20 > Cleaning out my mailbox; and I didn't want this to disappear. Back on 12/12 > Scott asked for a way to look at a YTS > response and differentiate between a TS error, and an Origin server error. > I *think* the general idea is that, whenever the origin server returns an > error; we return it to the client. > However, if there's a problem contacting the origin server, we should return > the appropriate HTTP response: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5 > including > 500 Internal Server Error > 501 Not Implemented > 502 Bad Gateway > 503 Service Unavailable > 504 Gateway Timeout > 505 HTTP Version Not Supported > and specify what Origin Server triggered the error in the Warning header: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46 > I think we could define our own warn code and use it specify the origin > server host (by name and IP): > 504 Gateway Timeout > Date: Wed, 17 Jan 2007 21:17:25 GMT > Warning: 599 l1.ycs.s1s.yahoo.com:80 "OS: us.yimg.com [66.218.71.81]" > But that's just a thought. Maybe mnot has a good suggestion -- he pointed us > towards the Warning: header, and may > know of good examples of it's use in the real world. > > > Comment 1 > by Chuck Neerdaels 3 years ago at 2007-01-18 16:33:15 > There's a pretty cool feature in TS, where it embeds codes into a Via > header (if those are turned on) where someone looking at the headers can see > whether it was a cache hit, an IMS hit, etc. As it moves through the state > machine, it appends characters to the string - and in the reply you get > something like [uN l oS f pS eN] which would translate to a user issuing a > no-cache pragma, that resulted in an origin server fetch, which was served > without error. It's pretty useful, so we might want to consider enabling > this. > There's a cheat sheet at > /dev/traffic/trunk/proxy/http2/README.via > chuck -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira