[jira] Created: (TS-309) Report OS Errors in Header

["Miles Libbey (JIRA)" <ji...@apache.org>]

Report OS Errors in Header
--------------------------

                 Key: TS-309
                 URL: https://issues.apache.org/jira/browse/TS-309
             Project: Traffic Server
          Issue Type: Improvement
            Reporter: Miles Libbey


(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.
-
You can reply to this email to add a comment to the issue online.