You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2013/09/04 20:22:53 UTC

[jira] [Resolved] (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 ]

Leif Hedstrom resolved TS-309.
------------------------------

       Resolution: Duplicate
    Fix Version/s:     (was: 5.0.0)
    
> 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
>
> (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