On 2006/06/12, at 2:42 AM, Hallvord R. M. Steen wrote:
The problem is that there's no way we can guarantee correct
behavior for new HTTP verbs whose semantics are not yet defined.
For instance, should a given method be idempotent? Are its results
eligible to be cached? Etc.
Gorm Haug Eriksen schrieb:
On Fri, 09 Jun 2006 10:56:20 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
So please leave this to those who actually control HTTP + extensions,
which is the IETF.
IETF should make an RFC much like http://www.ietf.org/rfc/rfc4229.txt
describing the http
* Julian Reschke wrote:
I don't understand this statement, because I'm not sure why XHR would
care at all what the verb is. HTTP fully defines how message
transmission works independently of the verb (with the single notable
exception being the responses to HEAD).
That depends on how much
On Wed, 07 Jun 2006 23:46:09 +0200, Mark Nottingham [EMAIL PROTECTED]
wrote:
Blindly standardising what one vendor does doesn't make sense;
We can certainly assume they have thought long and hard about a change
that WILL break existing content.
do you know *why* they consider it a
On Fri, 09 Jun 2006 10:56:20 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
Blindly standardising what one vendor does doesn't make sense;
We can certainly assume they have thought long and hard about a change
that WILL break existing content.
It would be really great if we could work
On Fri, 09 Jun 2006 10:56:20 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
So please leave this to those who actually control HTTP + extensions,
which is the IETF.
IETF should make an RFC much like http://www.ietf.org/rfc/rfc4229.txt
describing the http methods/verbs they actually
Ian Hickson schrieb:
On Wed, 7 Jun 2006, Mark Nottingham wrote:
Blindly standardising what one vendor does doesn't make sense; do you
know *why* they consider it a security feature?
The reputed security problems with various HTTP methods have been
brought up many times, but I have yet to
Charles McCathieNevile schrieb:
POST could be used to do so, but there is nothing in its defined
semantics that forces it to be used like that. POST hands the body to
something and says do with this as you see fit, PUT says begone, this
is your replacement.
Well. A server may replace a
Bjoern Hoehrmann schrieb:
* Julian Reschke wrote:
[...]
Could you propose specific text to be included in the specification with
respect to support for HTTP methods? It is not clear to me why we are
still discussing this, so having clear proposals for text would help a
lot.
Fair enough.
+1
On 2006/06/08, at 6:34 AM, Julian Reschke wrote:
Charles McCathieNevile schrieb:
POST could be used to do so, but there is nothing in its defined
semantics that forces it to be used like that. POST hands the body
to something and says do with this as you see fit, PUT says
begone,
On Thu, 8 Jun 2006, Charles McCathieNevile wrote:
Please be more specific. POST today allows *anything*.
Well, POST allows you to send anything. DELETE and PUT actually have
semantics that make them much more dangerous (and much more useful, if
you're building very simple publishing
On Wed, 7 Jun 2006, Mark Nottingham wrote:
Blindly standardising what one vendor does doesn't make sense; do you
know *why* they consider it a security feature?
The reputed security problems with various HTTP methods have been
brought up many times, but I have yet to see an explanation
On Thu, 08 Jun 2006 09:41:39 +1000, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 7 Jun 2006, Mark Nottingham wrote:
Blindly standardising what one vendor does doesn't make sense; do you
know *why* they consider it a security feature?
The reputed security problems with various HTTP methods
Mark Baker schrieb:
On 5/22/06, Mark Baker [EMAIL PROTECTED] wrote:
I think that was ACTION-145 on Gorm.
Doh, I meant to paste this;
http://www.w3.org/2006/webapi/track/actions/145
Hi,
first of all, I checked current implementations, using the verbs GET
(RFC2616), PROPFIND (RFC2518),
That's not my recollection of where the WG ended up at the F2F; I was
under the impression that someone was going to explain what the
security issues are, exactly.
I did have an AI to list HTTP methods, but Julian has done it for me ;)
On 5/22/06, Mark Baker [EMAIL PROTECTED] wrote:
I think that was ACTION-145 on Gorm.
Doh, I meant to paste this;
http://www.w3.org/2006/webapi/track/actions/145
Gorm Haug Eriksen wrote:
...
Please consider that if arbitrary methods can not be used with XHR,
future specification may be forced to use POST instead. So by banning
methods you don't know, you will make it more likely that people use
POST in the future, which is the contrary of what you
Anne van Kesteren [EMAIL PROTECTED]
Currently some browsers have a whitelist and others have a blacklist and
the group has resolved to go for a whitelist containing all safe methods
that currently exist, unless the IETF comes up with good reasons not to.
I disagree with this decision, I do
On Sun, 14 May 2006 13:59:34 +0200, Jim Ley [EMAIL PROTECTED] wrote:
There are currently some methods that can't be allowed for security
reasons and because such method smay be introduced in the future as
well allowing arbitrary method names does not seem like a good idea.
I think you need
On Sat, 15 Apr 2006 12:31:43 +0200, Pete Kirkham [EMAIL PROTECTED]
wrote:
I have worked with XMLHttpRequest (and also the Java http libraries)
and found it annoying that only a few of the WebDav and DeltaV methods
are supported. Often I've had to hack it with a server script to
tunnel the
I have worked with XMLHttpRequest (and also the Java http libraries)
and found it annoying that only a few of the WebDav and DeltaV methods
are supported. Often I've had to hack it with a server script to
tunnel the requests so that I end up with POST
http://example.com/my-stuff?method=MKACTIVITY
21 matches
Mail list logo
