Subject: Fwd: New Version Notification for draft-nottingham-proxy-status-00.txt

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Feb 2019 00:09:54 +1100

FYI - Piotr and I have been working on this for a bit, feedback appreciated.

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-proxy-status-00.txt
> Date: 20 February 2019 at 2:04:49 pm AEDT
> To: "Piotr Sikora" <[email-masked]>, "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-proxy-status-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-proxy-status
> Revision:	00
> Title:		The Proxy-Status HTTP Header Field
> Document date:	2019-02-20
> Group:		Individual Submission
> Pages:		17
> URL:            https://www.ietf.org/internet-drafts/draft-nottingham-proxy-status-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-proxy-status/
> Htmlized:       https://tools.ietf.org/html/draft-nottingham-proxy-status-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-proxy-status
> 
> 
> Abstract:
>   This document defines the Proxy-Status HTTP header field to convey
>   the details of errors generated by HTTP intermediaries.
> 
> Note to Readers
> 
>   _RFC EDITOR: please remove this section before publication_
> 
>   The issues list for this draft can be found at
>   https://github.com/mnot/I-D/labels/proxy-status [1].
> 
>   The most recent (often, unpublished) draft is at
>   https://mnot.github.io/I-D/proxy-status/ [2].
> 
>   See also the draft's current status in the IETF datatracker, at
>   https://datatracker.ietf.org/doc/draft-nottingham-proxy-status/ [3].
> 
>   Precursors that informed this work include (but are not limited to):
> 
>   o  https://docs.fastly.com/guides/debugging/common-503-errors
> 
>   o  https://support.cloudflare.com/hc/en-us/sections/200820298-Error-
>      Pages
> 
>   o  https://cloud.google.com/load-balancing/docs/https/https-logging-
>      monitoring
> 
>   o  https://docs.google.com/document/
>      d/1fMEK80KlpHcL4CwhniOupgQu4MDsxK4y4dKhthjjCMA
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Patrick McManus <[email-masked]>
Date: Wed, 20 Feb 2019 10:55:11 -0500

Thanks for doing this. What are your intentions/desires wrt httpbis and
this work?

(related nit - informational docs that establish registries and reviewers
don't seem right..)

-P

On Wed, Feb 20, 2019 at 8:13 AM Mark Nottingham <[email-masked]> wrote:

> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-nottingham-proxy-status-00.txt*
> *Date: *20 February 2019 at 2:04:49 pm AEDT
> *To: *"Piotr Sikora" <[email-masked]>, "Mark Nottingham" <
> [email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-nottingham-proxy-status-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-nottingham-proxy-status/
> Htmlized:
> https://tools.ietf.org/html/draft-nottingham-proxy-status-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-nottingham-proxy-status
>
>
> Abstract:

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Feb 2019 16:31:24 +1100

It'd be great to hear what people think; I think we'd like to talk about adoption in Prague if there's interest.

Cheers,

> On 21 Feb 2019, at 2:55 am, Patrick McManus <[email-masked]> wrote:
> 
> Thanks for doing this. What are your intentions/desires wrt httpbis and this work?
> 
> (related nit - informational docs that establish registries and reviewers don't seem right..)
> 
> -P
> 
>

---

From: Alessandro Ghedini <[email-masked]>
Date: Tue, 26 Feb 2019 19:53:46 +0000

> FYI - Piotr and I have been working on this for a bit, feedback appreciated.

This seems like a useful thing. We've had trouble with figuring out where
user-facing errors are generated among multiple internal proxies as well
as understanding the why by just looking at error logs, so this proposal
seems like it could provide a big improvement.

Though we'll need to consider the switch from internal logs to public header
very carefully.

Cheers