Subject: New issue: Need for an HTTP request method registry

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 06 Aug 2007 23:58:20 +0200

I see a need for an official HTTP request method registry to be
established, preferably maintained by IANA.

Comments?

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 00:05:06 +0200

> established, preferably maintained by IANA.

Yes.

Seems we should add this to the issues list.

Best regards, Julian

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 07 Aug 2007 10:17:17 +1200

in principle I agree.

However I would strongly caution against the proliferation of methods.

<horse:dead:flog>

since I write a proxy, I'm biased towards proxies, but every time a 
method is added to HTTP, we eventually get requests to support it.

Even if it is painful, we can at least do that since we're software-based.

But there are zillions of deployed hardware-based HTTP gateways that 
don't get firmware updates.  These will be broken for any new methods 
until they are replaced.  Many of these intercept connections as well :)

A layered approach might be a better solution to implementing new 
higher-level applications.  One that doesn't invalidate deployed 
servers, gateways etc.

e.g. use HTTP for the transport only, not the higher-level application 
layer.  It would solve a lot of compatibility issues for proxy and 
gateway vendors, reduce obsolescence and generally improve customer 
return on investment.  Furthermore it would restrict the scope of 
changes required for any functionality to only those parties involved 
(i.e. specific servers and clients) rather than all intervening HTTP 
infrastructure as well.

</horse:dead:flog>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 00:33:19 +0200

> However I would strongly caution against the proliferation of methods.

Ofcourse.

The issue is that today there already is a lot of methods, and not easy
to keep track of which method is defined in which RFC.

> method is added to HTTP, we eventually get requests to support it.

Same here. But at the same time HTTP is written with method
extensibility from start so I don't consider it an excuse..

> higher-level applications.  One that doesn't invalidate deployed 

Sure, but most HTTP extensions is not really higher level. More refining
the protocol to fit the requirements better.

But extreme care needs to be taken when inventing new methods, to not
fall into the same pitfall as for example WebDAV PROPFIND has done...

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 07 Aug 2007 10:56:36 +1200

> extensibility from start so I don't consider it an excuse..
that was my point regarding TCP.  Imagine if TCP had been written with 
TCP flag extensibility built in.

The success (in terms of interoperability and deployment) of TCP is due 
to several things:

1. simplicity
2. stability

any time you add complexity or change to a protocol, you reduce 
interoperability - which is arguably a protocol's prime raison d'etre.  
I'd like to see HTTP as successful as it can be.  By this reasoning 
however we'd never change anything.  I think we still need to address 
issues latent in the existing protocol, but functionality I think should 
only be added to a protocol where there is a clear benefit to a large 
majority of agents, and I don't see WebDAV in that category.

> fall into the same pitfall as for example WebDAV PROPFIND has done...

yes WebDAV was the main culprit I was thinking of, and would have been a 
good candidate for a higher-level layer over HTTP rather than an 
extension of it.

I guess the one down-side of a method registry might be a perceived 
condoning of proliferation of methods.  Not having one arguably is a 
disincentive to it.

I wonder what the landscape will look like 20 years from now, and 
whether there should be any initiative taken to purge some of these 
things from HTTP and move them into their own layer (perhaps a separate 
layer protocol) - cleaning up HTTP on the way and setting it in better 
stead for the future.  I guess there won't be much enthusiasm for 
something like that though - it's too easy to "hack" http for specific 
purposes, and if one doesn't really care about deployment issues (i.e. 
their system works), it's not painful enough to stop people doing it.  
Proxy vendors by and large are the ones that get the hit, since there's 
always someone that wants to use one of these applications through a proxy.

Regards

Adrien

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 01:47:50 +0200

> TCP flag extensibility built in.

Oh, well, it was and is.. the "Reserved" flags was for future extension,
and it's also relatively trivial to extend TCP with new TCP options. 

That's how we got Window scaling, SACK, Timestamping (Round-trip
measurements and PAWS), ECN, and a bunch of other less known TCP
extensions.

But unlike HTTP TCP extensions is more strictly controlled with more
people keeping a close eye on what is being done.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 07 Aug 2007 11:59:02 +1200

> and it's also relatively trivial to extend TCP with new TCP options. 
understood, although I did mean specifically the TCP flags field.  I 
don't think any TCP flag has been added for many many years if ever.

TCP flags IMO are akin to HTTP methods.  They define the set of states 
and state transitions etc.  TCP options are more akin to HTTP headers.  
They are modifiers rather than definers of state (if that makes any sense).

Adding methods and response codes to HTTP is like adding a new TCP 
flag.  Most people wouldn't even consider that an option, and wouldn't 
even start down that path.  It likely breaks any intermediaries as well 
as servers and clients

Adding new headers is like adding a new option to TCP (like SACK etc).  
That is a lot more approachable, but still highly significant and 
onerous.  It is normally a lot less likely to break existing infrastructure.

Anyway, I guess not that useful a simile.  The point I was trying to 
make is we shouldn't be adding new methods and status codes unless 
there's absolutely no other way to do something, and that thing really 
needs to be done.  There's pretty much always another way.

P.s sorry overlooked your point before about the registry being a place 
to find relevant RFCs.  I'd put my vote in for such a registry for that 
reason alone.

Regards

Adrien

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 02:19:55 +0200

> needs to be done.  There's pretty much always another way.

I don't share this view entirely. There is several valid reasons for
extending HTTP. HTTP is not a transport, it is an application protocol
with a specific focus.

Things like WebDAV certainly merits it's existence within HTTP. It's
just unfortunate that PROPFIND (and it's relatives) didn't get the
protocol attention it required before it got specified and relatively
widely deployed. But I don't consider it too late to fix, even if it
will take time.

Before extending HTTP one must carefully consider

a) Isn't there anything already in HTTP which can express what I am
after. I.e. could it be solved by defining a standard URI namespace
schema and content types, using existing methods?

b) If not, is HTTP really the proper protocol for the task?

Selecting HTTP only because it runs over port 80 and is often accepted
by firewalls is not a valid reason to use HTTP or to extend HTTP, even
if this is probably the most common reason why more and more non-web
applications layer themselves over HTTP..

Regards
Henrik

---

From: James M Snell <[email-masked]>
Date: Mon, 06 Aug 2007 17:28:46 -0700

I don't see what this would buy us.

- James

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 6 Aug 2007 19:07:46 -0700

On Aug 6, 2007, at 4:59 PM, Adrien de Croy wrote:
> TCP flags IMO are akin to HTTP methods.  They define the set of  
> states and state transitions etc.  TCP options are more akin to  
> HTTP headers.  They are modifiers rather than definers of state (if  
> that makes any sense).
>
> flag.  Most people wouldn't even consider that an option, and  
> wouldn't even start down that path.  It likely breaks any  
> intermediaries as well as servers and clients
>
> Adding new headers is like adding a new option to TCP (like SACK  
> etc).  That is a lot more approachable, but still highly  
> significant and onerous.  It is normally a lot less likely to break  
> existing infrastructure.
>
> Anyway, I guess not that useful a simile.  The point I was trying  
> to make is we shouldn't be adding new methods and status codes  
> unless there's absolutely no other way to do something, and that  
> thing really needs to be done.  There's pretty much always another  
> way.

No, sorry, that is just wrong.  HTTP has been defined such that
intermediaries do not need to know the meaning of methods, and hence
can forward extension methods just as safely as they forward header
fields.  The exception is when the intermediary is specifically
configured to block unknown methods for local policy reasons, and it
is for that reason that we *want* method-like extensions to be
communicated as methods.  We want people to be able to control
their own networks.

If an intermediary is accidentally blocking unknown methods,
then it is simply broken and should be replaced by something that
actually implements HTTP.

New methods should be added when an extension signifies a new type
of action (e.g., PATCH is better than PUT+Content-Range).  New status
codes should be added when the response enables automatic handling by
a client that is distinct from the existing codes.  If we let broken
implementations determine the meaning of HTTP, then HTTP will slowly
degrade as implementors make mistakes over time.

....Roy

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 07 Aug 2007 16:25:34 +1200

Roy T. Fielding wrote:
>> states and state transitions etc.  TCP options are more akin to HTTP 
>> headers.  They are modifiers rather than definers of state (if that 
>> makes any sense).
>>
>> etc).  That is a lot more approachable, but still highly significant 
>> and onerous.  It is normally a lot less likely to break existing 
>> infrastructure.
>>
>> there's absolutely no other way to do something, and that thing 
>> really needs to be done.  There's pretty much always another way.
>
OK, I think I understand your points.  I didn't pick it up from my 
reading of the spec though, and therefore perhaps naively assumed that a 
policy control device (being an intermediary interested in enabling 
administrative policy control) would by default block unknown methods, 
since it can't tell they are safe.  This is common practice in the 
security arena - block whatever you don't understand.  Putting new 
functionality into new methods rather than burying them in some XML 
payload would indeed make it easier to administratively block - thanks 
for that clarification.

The bigger issue then becomes education of system admins as to what 
these methods really mean, and what happens if they are blocked.  User 
education is expensive.

Also that of allowing a system to be configured to recognise valid 
methods (i.e. not just a hard-coded list of known methods at time of 
compilation).

And what does it all mean for caching?

I imagine there are enough naive implementations of gateways out there 
that this is a significant issue. 

Another example of the perpetual tug of war between complexity and 
conformity I guess.

> degrade as implementors make mistakes over time.
I agree we shouldn't let broken implementations define HTTP - that's the 
tail wagging the dog.  I do think we should however always keep in mind 
implementation difficulties when designing protocols.  Sometimes it 
appears that bug-free implementation has been considered a given where 
in fact it's non-trivial.  Unfortunately it's us fallible humans that 
keep implementing things, and mistakes will always happen, and we will 
always be lazy and try and implement as little of a spec as we 
absolutely need (whether or not we can truly perceive how much that 
is).  Humans seem to have a tendency to complexify things over time 
rather than simplify them - it's a common evolutionary process, 
especially with software (just look at Windows Vista compared to XP 
compared to 2000).  Consumers on the other hand wish things to be 
increasingly simplified. 

thanks

Adrien

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 12:07:52 +0200

> And what does it all mean for caching?

Not much. There is already a catch-all phrase defining how caches should
operate when seeing unknown methods. All cached entities of the
request-URI is invalideted.

This phrase needs to be refined a bit to avoid unneeded cache
invalidations, but that's an optimization.

> Another example of the perpetual tug of war between complexity and 

And is why the set of REQUIRED methods in HTTP should be kept down to a
minimum, with most of the methods only required in their context. i.e.
WebDAV methods only required in clients and servers supporting WebDAV.

> implementation difficulties when designing protocols.

Yes.

> Sometimes it 
> is).

Sure, and equally true no matter what level things gets implemented at.

This said it's not very hard to extend HTTP without breaking the core.
But some aspects of the core is not understood well enought currently
due to the complexity of the specification and this is something that
needs to be addressed. In itself the features is not complex.

- The self-contained message nature of the protocol and transport
independence (violated by NTLM/Negotiate).

- Cache model with Request-URI, ETag, Content-Location, as seen in
recent discussions. (problem for WebDAV PROPFIND, but not strictly a
violation)

- ETag in general.

> Humans seem to have a tendency to complexify things over time 

Commitees have that tendency yes. But generally not individuals trying
to make their life. And with proper focus comitees can occationally
simplify things..

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 12:29:15 +0200

> method is added to HTTP, we eventually get requests to support it.

Well, you probably only get them if you don't support it out of the box? 
Why don't you? The method transmission semantics are defined in RFC2616, 
and apply to all methods (minus CONNECT, perhaps).

> until they are replaced.  Many of these intercept connections as well :)

If they don't support extension methods, they are already broken right now.

> layer.  It would solve a lot of compatibility issues for proxy and 

...but HTTP is an application protocol. The transport is TCP...

 > ...

Some more thoughts:

- RFC2616 already tells you what to do with unknown methods,

- unknown methods by definition aren't less safe as POST, as POST can 
already mean "anything",

- blocking unknown methods only results in applications using POST 
instead, which makes life harder for intermediates, not simpler,

- a method registry should require to state safeness (can I follow a 
redirect automatically?) and idempotence (can I retry?).

Finally, we spent an enormous time discussing this on the webapi mailing 
list, when defining XmlHttpRequest (XHR). Turns out that IE7 and Opera 
are broken, in that they block unknown methods. On the other hand, 
Firefox and MSXML's ActiveX control work as they should.

Best regards, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 7 Aug 2007 13:50:45 +0100

> method is added to HTTP, we eventually get requests to support it.

Why don't you support all unknown methods already?  RFC2616 is quite
clear that proxies shouldn't need to be changed as new methods are
deployed.

If you are filtering to allow only particular methods, you should at
least have the option on some configuration screen of your device to
add new permitted methods by name, right?

> until they are replaced.  Many of these intercept connections as well :)

Again, why are they broken?  Is it just policy-based filtering?

> (i.e. specific servers and clients) rather than all intervening HTTP 

How is "application vs. HTTP" any different from "application vs. TCP"?

People are writing applications that run over HTTP as transport (and
hackily; see server-push AJAX) because general TCP/IP is not available
to them for infrastructure reasons.  In effect, there's firewalls and
NATs and application limitations (e.g. it must run in a browser) all
over the place which limit the available transport to HTTP over
TCP/IP.

10 years ago, it was more like TCP/IP was everywhere.  Applications
could use that as a near universal transport.

In 10 years time, won't we see exactly the same infrastructure problem
repeated with something-over-HTTP, just moved up a level?

Perhaps it's inevitable.

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 17:39:00 +0200

> repeated with something-over-HTTP, just moved up a level?

If the protocol isn't allowed to expand then yes, very likely, as people
will then define more and more application protocols on top of HTTP
which really should have been done within HTTP. Consider for example the
situation if WebDAV only had GET/POST/HEAD to work with and not allowed
to expand.. we would then have seen a standardization on POST body
content, and intermediaries wishing to enforce policies on "PostDAV"
would need to parse not only HTTP but also the "PostDAV POST application
format".

However, adjusting the protocol to deal with those abusing HTTP as
transport it in absense of a TCP/IP transport is not something we should
have on the agenda. There is already SOCKS covering that use case and
doing a very good job of it. But it's a sad truth that it has become
common practice to use HTTP for this purpose.

Regards
Hernik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 17:53:33 +0200

> I don't see what this would buy us.

- Coordination between HTTP extensions, and avoidance of duplicate work.
- An easier path for people to find the meaning of a method without
everyone having to index the RFCs themselves.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 17:59:38 +0200

Yes.

> everyone having to index the RFCs themselves.

Also, avoiding that people white-list HTTP methods and then forget some 
(yes, Microsoft & Opera, I'm talking to you! :-).

BTW, there's 
<http://greenbytes.de/tech/webdav/common-index.html#rfc.index.M>. But of 
course that's not a substitute for a proper registry.

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Tue, 07 Aug 2007 09:40:34 -0700

Heh.. I guess I'd just as soon read the RFC's :-) ... but I understand
your point.

- James

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 Aug 2007 18:43:10 +0100

>established, preferably maintained by IANA.
IMHO, if one needs to check more than 3 documents to find all methods, 
then a new registry is needed.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 07 Aug 2007 18:44:48 +0100

> then a new registry is needed.

I should just add that HTTP clearly demonstrated that new methods can be 
added, which serves as an additional argument in favor of the registry.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 7 Aug 2007 10:57:47 -0700

On Aug 6, 2007, at 7:07 PM, Roy T. Fielding wrote:

>> HTTP headers.  They are modifiers rather than definers of state  
>> (if that makes any sense).
>>
>> significant and onerous.  It is normally a lot less likely to  
>> break existing infrastructure.
>>

+1.  I've never understood why, in the worst case, an intermediary  
couldn't have a configuration file or admin UI that allowed humans to  
add or remove whitelisted or blacklisted method names.  It seems  
extraordinarily backwards, especially nearly 10 years after WebDAV  
first appeared on the 'Net, to require software updates to handle new  
methods!

Lisa

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 22:30:12 +0200

On tis, 2007-08-07 at 10:57 -0700, Lisa Dusseault wrote:

> add or remove whitelisted or blacklisted method names.

Can only speak for Squid, and there the reason why it doesn't support
"any unknown method" is just laziness. But we do have an configuration
directive where the admin can add a number of extension methods.

> It seems extraordinarily backwards, especially nearly 10 years after
> WebDAV first appeared on the 'Net, to require software updates to
> handle new methods!

It is.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 07 Aug 2007 23:10:22 +0200

> then a new registry is needed.

A quick inventory of HTTP method definitions:

RFC2616
RFC2068 (defines more methods than 2616)
RFC2818
RFC3253
RFC3648
RFC3744
RFC4437
RFC4791
RFC4918

Probably missed some.

Regards
Henrik

---

From: Eric Lawrence <[email-masked]>
Date: Tue, 7 Aug 2007 14:25:32 -0700

I very much support and look forward to creation of a registry for HTTP methods.

As for the notion that Microsoft allow-lists HTTP methods and "forgot" some, I assume you're referring to the list of supported methods for XMLHTTPRequest?  If that's the case, it's important to note that not all methods should be considered safe for ~script~ to use.  Hence, for security reasons, there's a restriction as to what methods may be used by XMLHTTPRequest.

If there's a specific method currently not permitted by XMLHTTPRequest which you believe should be, please let me know.

Thanks,

Eric Lawrence
Program Manager
Internet Explorer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Tuesday, August 07, 2007 9:00 AM
To: Henrik Nordstrom
Cc: HTTP Working Group
Subject: Re: New issue: Need for an HTTP request method registry

Yes.

BTW, there's

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Aug 2007 23:45:32 +0200

> If there's a specific method currently not permitted by XMLHTTPRequest which you believe should be, please let me know.

Hi Eric,

see thread at 
<http://lists.w3.org/Archives/Public/public-webapi/2007Feb/thread.html#msg109>.

In general, I think all methods should be allowed unless proven to be a 
security problem.

If you really insist on a white list, please allow minimally the methods 
defined in:

RFC3253, RFC3648, RFC3744, RFC4437, RFC4791, RFC4918, 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html>, 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
and <http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-08.html>.

Best regards, Julian

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 08 Aug 2007 10:15:36 +1200

> first appeared on the 'Net, to require software updates to handle new 

One could also argue that a security product that allowed unknown 
methods through was also "backwards".  Proxies with a security focus are 
about control.  To control, first one must understand.  Therefore in 
order to provide an effective security product, each controlled method 
must be firstly recognised then understood (for finer-grained control) 
by the proxy.  Recognition of a method in a product can be configurable, 
but understanding has to be built-in.

The concept of allowing unknown methods without that being an explicit 
wish of the administrator is incongruous.  In order for that to be an 
explicit wish, the administrator needs to understand its implications.  
So even if we add an admin control about whether to allow unknown 
methods or not, (or worse still allowing the admin to set allow/deny on 
any entered method name) trying to explain the meaning of such a control 
to users is costly.  What do we choose for the default setting of such a 
control?  The seemingly-humble default setting has wide-reaching 
implications, knowing that 99% of people never touch it, or ever bother 
to figure out what it means.  Choose the wrong value and there's 
trouble.  Allowing all unknown methods would seem to be the safe option 
from a tech-support point of view, but is unpalatable from a security POV.

Also the semantics of all methods aren't exactly the same.  CONNECT and 
TRACE for example pose separate kinds of problems for proxies.  Are we 
saying that any new method must work the same way as the old ones so 
that they can go through a proxy?  That seems to be a fairly significant 
limitation on the scope of future expansion if you ask me.  For instance 
a method to pre-negotiate transfer of a large message body from a client 
to a server wouldn't fit into this category (but I see more evidence of 
a requirement for it every day, and not only related to "broken" NTLM).

In the end, let's just accept that the existence of proxies that do only 
allow a hard-coded set of methods is proof enough that it is possible to 
create such a proxy, and rather than judging, we could look to see why 
it is that it happened in the first place.  There are often many things 
in a spec that an implementor decides (rightly or wrongly) are incorrect 
or undesired behaviour.  SMTP for instance is full of them.  The 
implementor consoles themselves with the rationale that "this spec was 
written back in the day when the Internet was a big happy family, with 
no regard to security - things are different now", and that gives them 
the mandate (in their mind) to do whatever they wish. So it's not just a 
matter of blindly following the spec.  There are often conflicting 
pressures.

Someone that studies complexity would look at this and laugh, as it's an 
obvious complexity-related problem.  HTTP isn't compartmentalised 
(unlike layered protocol systems), so complexity becomes an 
ever-increasing issue.  The rate of increase in interdependencies is 
like geometric.

Anyway, I wish I had an answer for how to get people to read 
documentation at all let alone properly.  It goes against human nature 
it seems - like trying to fight the weather. In the end, the longer the 
document, and the less familiar language it uses, and the more 
cross-referencing that is required, the less likely it will be 
completely successful in its mission of imparting its content to the 
reader. 

At least thanks to the people on this list I know we need to make some 
changes (not quite sure what though) - appreciate that thanks. 

Regards

Adrien

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 08 Aug 2007 10:40:56 +1200

Julian Reschke wrote:
>
> In general, I think all methods should be allowed unless proven to be 
> a security problem.
>
I think there's a compelling argument to be made for denying all methods
unless proven (or at least strongly believed) to be safe.

Waiting for something to be proven unsafe isn't safe.  If I were MS, I
would definitely adopt the more cautious approach.

---

From: Jeffrey Mogul <[email-masked]>
Date: Wed, 08 Aug 2007 16:48:00 -0700

Adrien de Croy <[email-masked]> writes:
    
    in principle I agree.

Agreed.

Note, however, that IANA registries are established at
http://www.iana.org/numbers.html as a triple of

   (registry, defining-rfc, Registration/Assignment Procedures)

There are a number of possibilities for "Registration/Assignment
Procedures".  For example, the HTTP content-coding registry
is "First Come First Serve with specification recommended"
whereas others require review or approval, such as "IETF consensus"
or "Expert review".  I believe that BCP26/RFC2434 ("Guidelines for
IANA Considerations") is the latest document that defines how
this works; it suggests a set of example policies, but I think
BCP26 also allows inventing a new policy.

I suggest that the HTTP-methods registry set this policy from
BCP26:

      Standards Action - Values are assigned only for Standards Track
           RFCs approved by the IESG.

           Examples: MIME top level types [MIME-REG]

This would probably prevent much in the way of new methods;
it might even slow things down too much for some people's
tastes.

By the way, I'm strongly in favor of a registry, since it
does provide unambiguous documentation.  It might be useful
for the registry's scheme to include a field such as
"core" or "non-core" (or perhaps with more values possible)
so that implementors have some guidance as to which are
mandatory to implement.

-Jeff

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 9 Aug 2007 14:25:16 +0100

> would definitely adopt the more cautious approach.

And yet, I imagine all products allow POST, and with POST you can do
anything at all over HTTP, if the client and server wish.

Indeed, there are a few implementations which do tunnel arbitrary
protocols over POST, to get around restrictions.  I can imagine myself
coding a client which, when it detects that NEWMETHOD (or whatever)
isn't working, it falls back to tunnelling the equivalent over POST,
provided the server will understand it.  (Much like the cascade of
methods we currently try in sequence to make certain web apps work
everywhere.)

Why is that allowed?  It's not meant to be a provocative question, but
hoping for some thought as to why POST to a server is ok, but some
arbitrary new method is not.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 9 Aug 2007 14:11:58 +0100

>    first  appeared on the 'Net, to require software updates to handle new

+1.  It seems pretty broken to me.

However, even when intermediaries _are_ configurable, organisational
difficulties can make it hard to deploy applications that need new
configurations.

For example, someone may access a web server, and it works fine, and
then they try connecting to the same place using a WebDAV authoring
tool, and it just breaks, while it works fine for someone else in the
organisation.

It may be quite difficult to locate and reconfigure all the
intermediaries which are filtering the methods.  Particularly as most
applications over the same route and protocol work fine, and
especially if the intermediary's response is to just close the
connection.  And it may be impossible for the server admins or the
users to do the changes.

Unfortunately, using anything other than GET/POST in HTTP is one of
those things which changes the infrastructure from "always works or
doesn't work" to "works for some applications and not others".  There
is hardly any use, by most users, other than GET/POST.  So it all
seems to work, infrastructure maintainers are happy, then one new
application doesn't work properly, and it's a challenge to debug
because it's relatively obscure protocol usage.

TCP/IP (and IP generally) suffered a similar problem when ECN,
Explicit Congestion Notification, was added.  Some routers blocked all
IP packets with those bits set, as a precaution.  They were called
"reserved" and should have been ignored, but the routers were cautious
because you never know if a node inside a protected network will behave
reasonably on seeing those bits.

It took many years before it was possible to deploy this standard IETF
feature on public-facing servers, entirely because of this router
filtering, and I'm still not sure how many users won't be able to
access a server that does.

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 09 Aug 2007 17:14:30 +0200

> access a server that does.

Seeing this from a client (proxy) perspective and ECN brokenness is a
quite noticeable problem. Even TCP Window Scaling is causing a lot of
grief still (probably even more than ECN).

But broken HTTP implementations (both server and client) is far more
common.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 10 Aug 2007 10:02:29 +1200

> methods we currently try in sequence to make certain web apps work
If I was thinking of deploying a new application over HTTP I wouldn't 
even consider for a minute using anything other than GET and POST in the 
first instance, rather than using it as a fall-back. It's not worth the 
angst of developing the new method, trying to get it standardised etc 
etc etc, finding out many intermediaries block it, and having to code a 
fall-back to GET/POST in the end anyway and then having 2 versions of 
the thing.  Much less hassle to just layer it over GET/POST in the first 
place, and I'm sure that's why it has been done that way more often than 
the other (I believe).

But that's the argument for using HTTP as a transport.  :)  There are of 
course other benefits of using HTTP as a transport for this - namely 
that you can then choose to layer your higher-level protocol over other 
protocols as well, rather than being chained eternally to HTTP.

> arbitrary new method is not.
human nature - familiarity breeds contempt and all that.  People writing 
these things are familiar with GET/POST, and whats more nothing much 
works without it.  Lots of things still work without other rarely-used 
methods.  Putting out a product without GET and POST support would be 
like trying to sell a car with only 1 wheel and no engine.  Putting out 
a product without some of the other methods would be more like trying to 
sell a car with only a 4 speaker sound-system instead of 6.

I'm sure people don't consider POST to be entirely safe, but they know 
they don't even have a product if they don't support it.

Also, POST doesn't always work either.  Especially with NTLM.

And I know NTLM is "broken" and "unsupported", and all sorts of other 
violations of the spec, but on the other hand millions and millions of 
people have to use it.  To use digest on a windows platform you can't 
auth against the windows or AD user database unless you re-write that 
database (since there's no conversion between one way hashes).  I can't 
see MS doing that when they can and have just kludged NTLM into HTTP.  
Is the fact that they had to kludge it in without support an indication 
of a failing in HTTP?

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 10 Aug 2007 16:10:49 +0200

On fre, 2007-08-10 at 10:02 +1200, Adrien de Croy wrote:
> To use digest on a windows platform you can't 

MS AD supports Digest if you want. But it's not enabled by default due
to security concerns. Apparently this is because they then store the
plaintext password in the internal database and not the less sensitive
Digest H(A1) values (probably to avoid being dependent on the realms
used). Every existing user wanting to use Digest only needs to change
their password after this change to have the AD object updated with the
required password details.

Same for Novell eDirectory with it's "universal password" support.

Regards
Henrik

---

From: Leif Johansson <[email-masked]>
Date: Fri, 10 Aug 2007 17:11:33 +0200

> Same for Novell eDirectory with it's "universal password" support.
I'm not sure If you meant that as a good or bad thing :-) A large
set of users never "just" decide to change their passwords as
anyone who has operated a large user store with several keys
per user (eg a kdc).

MS AD and other KDCs store plaintext passwords to make
key type migration possible.
   
    Cheers Leif

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 10 Aug 2007 18:09:39 +0200

> anyone who has operated a large user store with several keys

Quite many have password aging enabled, requiring users to periodically
change their password.

Regards
Henrik

---

From: Leif Johansson <[email-masked]>
Date: Fri, 10 Aug 2007 20:04:06 +0200

> Quite many have password aging enabled, requiring users to periodically
I can only speak from my operational experience with such
things - I've never found password aging good or fast enough
when needing to deploy a new keytype/enctype.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Aug 2007 13:39:09 +1000

http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i72

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