Subject: http methods

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 13 Aug 2013 09:30:18 +0200

http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-12 seems
to have the current method registrations. I'm not a web services guy, so my
ignorance is expected, but wow, I didn't realize there were so many. Can
someone explain if all these are truly necessary?

I'm asking this since a colleague of mine wrote this blog post (
http://www.onebigfluke.com/2013/08/lets-remove-verbs-from-http-20.html), so
I decided to look into it a bit. Note that I recognize that HTTP/2.0 is not
the place to remove methods, but I'm curious if there has been any effort
to simply HTTP by removing some exotic methods. If so, I think that'd be
nice.

I'm not really looking to champion a simplification effort here since I
have other bike sheds more worthy of my paint, but I just wanted to see if
it'd be easy to drop some unused methods.

Cheers.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 13 Aug 2013 07:37:03 +0000

In message <CAA4WUYg349TDDg6ZU4YSDNfhn39JLmrFbPETG+GQ2Ym+xb=[email-masked]>
, =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= writes:

>http://www.onebigfluke.com/2013/08/lets-remove-verbs-from-http-20.html)

And he's absolutely right:  There should only be two verbs: "READ-ONLY"
and "READ-WRITE" aka GET/POST.

The rest is just there to slow things down and introduce bugs.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: James M Snell <[email-masked]>
Date: Tue, 13 Aug 2013 01:04:05 -0700

Not worth even considering or discussing. If you don't think any particular
method is useful, ignore it.
On Aug 13, 2013 12:32 AM, "William Chan (陈智昌)" <[email-masked]>
wrote:

> http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-12seems to have the current method registrations. I'm not a web services guy,
> so my ignorance is expected, but wow, I didn't realize there were so many.
> Can someone explain if all these are truly necessary?
>
> http://www.onebigfluke.com/2013/08/lets-remove-verbs-from-http-20.html),
> so I decided to look into it a bit. Note that I recognize that HTTP/2.0 is
> not the place to remove methods, but I'm curious if there has been any
> effort to simply HTTP by removing some exotic methods. If so, I think
> that'd be nice.
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Aug 2013 12:48:38 +0200

On 2013-08-13 09:30, William Chan (陈智昌) wrote:
> http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-12
> seems to have the current method registrations. I'm not a web services
> guy, so my ignorance is expected, but wow, I didn't realize there were
> so many. Can someone explain if all these are truly necessary?

Are they all needed? No. Are some of them needed? Yes.

Is there any gain by "removing" them? No. HTTP components do not need to 
understand "extension" methods in order to properly deal with them.

> I'm asking this since a colleague of mine wrote this blog post
> (http://www.onebigfluke.com/2013/08/lets-remove-verbs-from-http-20.html), so
> I decided to look into it a bit. Note that I recognize that HTTP/2.0 is

Removing uncommon methods doesn't simplify HTTP any more then removing 
uncommon status codes or header fields.

> have other bike sheds more worthy of my paint, but I just wanted to see
> if it'd be easy to drop some unused methods.
>
> Cheers.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Aug 2013 12:51:36 +0200

On 2013-08-13 10:04, James M Snell wrote:
> Not worth even considering or discussing. If you don't think any
> particular method is useful, ignore it.

Right.

Where "ignore" essentially means: treat it the same way as "POST".

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Aug 2013 12:57:47 +0200

> The rest is just there to slow things down and introduce bugs.

I believe what you say is based on the point of view of a very specific 
component.

In particular, it would be great if you could explain how exactly 
extension methods "slow things down" or "introduce bugs". Example?

Best regards, Julian

---

From: Roberto Peon <[email-masked]>
Date: Tue, 13 Aug 2013 08:24:11 -0700

I think the effort of limiting the verbs (or making them self-descriptive,
e.g. safe-or-not, body-or-not, etc.) is probably useful.
I intend to spend zero effort towards it, and I hope that this group does
not-- this seems like something outside of our charter, would definitely
slow us down.
Perhaps a BOF to charter some other effort on this? Or is this in charter?

-=R

On Tue, Aug 13, 2013 at 3:57 AM, Julian Reschke <[email-masked]>wrote:

>> In message <**CAA4WUYg349TDDg6ZU4YSDNfhn39JL**mrFbPETG+GQ2Ym+xb=ajA@mail.
>> **gmail.com <[email-masked]>>
>> , =?UTF-8?B?**V2lsbGlhbSBDaGFuICjpmYjmmbrmmI**wp?= writes:
>>
>>> http://www.onebigfluke.com/**2013/08/lets-remove-verbs-**
>>> from-http-20.html<http://www.onebigfluke.com/2013/08/lets-remove-verbs-from-http-20.html>
>>> )
>>>
>>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 13 Aug 2013 10:54:40 +0000

>uncommon status codes or header fields.

Can you please explain what the word "simplify" means to you ?

If ditching a load of unnecessary bells and whistles reduces the
size of the specification by 10%, it would clearly count as a
simplification where I come from.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 13 Aug 2013 11:06:54 +0000

>I believe what you say is based on the point of view of a very specific 

I say this from the perspective I hold on HTTP/2.0:

	  1 Tbit/s per machine or it doesn't matter.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Aug 2013 11:18:31 +0200

> 	  1 Tbit/s per machine or it doesn't matter.

Again: what does this have to do with the size of the vocabulary?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Aug 2013 11:21:13 +0200

> simplification where I come from.

We were talking about extension methods. These are not part of the base 
specification. They do not contribute to the size of the spec.

And no, the size of the specification is not a good measure for the 
complexity of a protocol.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 16 Aug 2013 09:42:23 +0000

>Again: what does this have to do with the size of the vocabulary?

It has something to do with how much work you have to do to find
out how to treat/route a request.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 16 Aug 2013 09:45:39 +0000

>complexity of a protocol.

I beg to differ.

If you can't explain it without using hundreds of pages, you're doing it wrong.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Aug 2013 13:56:39 +0200

> out how to treat/route a request.

How does the existence of extension methods makes that *harder*? If 
people tunnel through POST you will have to inspect custom headers 
and/or payloads to get the same information.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Aug 2013 13:55:37 +0200

> If you can't explain it without using hundreds of pages, you're doing it wrong.

I can explain "it" without hundreds of pages.

Best regards, Julian