You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "James Peach (JIRA)" <ji...@apache.org> on 2013/06/27 05:16:20 UTC
[jira] [Updated] (TS-309) xdebug: Report OS Errors in Header
[ https://issues.apache.org/jira/browse/TS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Peach updated TS-309:
---------------------------
Summary: xdebug: Report OS Errors in Header (was: Report OS Errors in Header)
> xdebug: 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
> Labels: A
> Fix For: 3.5.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
For more information on JIRA, see: http://www.atlassian.com/software/jira