I'll now explain that. Let A is the host-under-debugging (HUD). There is
another host, B, which is debugger. Let there is some new HTTP server
software on A. B's sending requests with different methods, headers and
entity to test A for appropriate processing of headers. Let B is sending
the request with header X-Foo, which is to be used or already used
widely among the Internet. But A does not recognize it. But it is not
easy for developers to get known this. If discussed header is used, B
testers can simply analyze A's answer (as it is to be done at all) to
find out the problem and fix it. That is debugging purpose, IMO.
Hope I explained everything clearly.
Any suggestions are welcome.
All the best,
16.12.2010 17:46, Daniel Stenberg wrote:
On Thu, 16 Dec 2010, Mykyta Yevstifeyev wrote:
You may find some related discussions on
dated from Monday, 22 November 2010 and Tuesday, 23 November 2010
The only tiny piece of explanation I can find there is
where you say "But aren't debugging purposes a weighty argument?".
Does this mean that debugging HTTP clients(?) and servers(?) is your
primary purpose for this feature? In what way does this help you debug?
I've been developing (and debugging) HTTP clients for over a decade
and I've not missed this header. I'm genuinely trying to understand
the use case and what benefit this header is to bring for that
purpose, so that I can read the draft with that in mind.
So please, even if this is repeating something you've expressed
before, can you enlighten us (again) exactly in what ways you intend
to use this header/feature?
(If someone else have any good suggestions, that'll do fine as well!)
Ietf mailing list