On Sat, 22 Apr 2006, Maciej Stachowiak wrote:
Let's face it, XMLHttpRequest only offers access to a subset of HTTP
protocol features, this is not avoidable, now let's pick that subset
based on pragmatic considerations, not theoretical purity.
Hear hear.
--
Ian Hickson
On Sat, 22 Apr 2006, Maciej Stachowiak wrote:
In this case, an example of a spec using non-uppercase http method
names, or of a server requiring such, would demonstrate the need for the
feature. Anne demonstrated the need to uppercase 'get' and 'post' by
showing widely deployed JS
On Sun, 23 Apr 2006 05:18:24 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
That being said, whether all methods are uppercased or only the methods
that get significant use, is not really a major issue. But let's not
just casually increase spec complexity without doing our due
On Apr 23, 2006, at 11:51, Anne van Kesteren wrote:
On Sun, 23 Apr 2006 05:18:24 +0200, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
That being said, whether all methods are uppercased or only the
methods that get significant use, is not really a major issue. But
let's not just casually
On Apr 21, 2006, at 9:33 AM, Mark Nottingham wrote:
The specs last a *lot* longer than the current versions of Mozilla,
Safari and IE.
And implementations ignoring what the spec says can last even longer
than the spec.
There's a place for making sure you have a path from the current
On Apr 21, 2006, at 12:38 PM, Ian Hickson wrote:
On Fri, 21 Apr 2006, Mark Nottingham wrote:
There's a place for making sure you have a path from the current
implementations to the new standard, but this isn't it. Specifying
this
behaviour well isn't going to cost anything; some
On Apr 23, 2006, at 02:00, Maciej Stachowiak wrote:
On Apr 21, 2006, at 12:53 PM, Mark Nottingham wrote:
How about
1) always uppercase anything matching (case-insensitive) GET
POST PUT DELETE
2) everything else gets sent as-is
This sounds viable but also harder to implement than
On Fri, 21 Apr 2006 06:46:51 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
On Apr 21, 2006, at 00:18, Mark Nottingham wrote:
Make it a SHOULD and twiddle your CR exit criteria to take it into
account; in the long term, implementations will sort themselves out.
My thoughts exactly.
A
The specs last a *lot* longer than the current versions of Mozilla,
Safari and IE.
There's a place for making sure you have a path from the current
implementations to the new standard, but this isn't it. Specifying
this behaviour well isn't going to cost anything; some
implementations
On Fri, 21 Apr 2006 18:33:57 +0200, Mark Nottingham [EMAIL PROTECTED]
wrote:
The specs last a *lot* longer than the current versions of Mozilla,
Safari and IE.
Sure, so does content.
There's a place for making sure you have a path from the current
implementations to the new standard,
On Fri, 21 Apr 2006, Mark Nottingham wrote:
There's a place for making sure you have a path from the current
implementations to the new standard, but this isn't it. Specifying this
behaviour well isn't going to cost anything; some implementations won't
be conformant for a little while,
On 2006/04/21, at 11:13 AM, Anne van Kesteren wrote:
There's a place for making sure you have a path from the current
implementations to the new standard, but this isn't it. Specifying
this behaviour well isn't going to cost anything; some
implementations won't be conformant for a
Anne van Kesteren wrote:
On Tue, 11 Apr 2006 23:54:43 +0200, Bjoern Hoehrmann [EMAIL PROTECTED]
wrote:
* Web APIs Issue Tracker wrote:
ISSUE-75: Is method case-sensitive?
We resolved that yes, the parameter is case-sensitive. This implies that
scripts like those in the draft
On Thu, 20 Apr 2006 22:09:32 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
One argument is that it's simply impossible to work around an XHR
implementation that changes the casing in a way that the server doesn't
expect. For example if the server wants a 'doit' method and the XHR
Jonas Sicking wrote:
One argument is that it's simply impossible to work around an XHR
implementation that changes the casing in a way that the server doesn't
expect. For example if the server wants a 'doit' method and the XHR
implementation case folds to uppercase, the script author will
Boris Zbarsky wrote:
Jonas Sicking wrote:
One argument is that it's simply impossible to work around an XHR
implementation that changes the casing in a way that the server
doesn't expect. For example if the server wants a 'doit' method and
the XHR implementation case folds to uppercase, the
+0200, Bjoern Hoehrmann [EMAIL PROTECTED]
wrote:
* Web APIs Issue Tracker wrote:
ISSUE-75: Is method case-sensitive?
We resolved that yes, the parameter is case-sensitive. This implies that
scripts like those in the draft are essentially incorrect since there is
no 'get' method yet. I think
On Thu, 20 Apr 2006 23:38:56 +0200, Julian Reschke [EMAIL PROTECTED]
wrote:
In the end, we want to have these clients/libraries fixed, right?
I guess that's the question. Is it sensible to implement it as
case-sensitive knowing that you probably break content? (Such as the
examples in
On Thu, 20 Apr 2006 23:42:39 +0200, Mark Baker [EMAIL PROTECTED] wrote:
I'm not aware of any HTTP extension methods which use a lower case
character, so why not make method case-insensitive, but prescribe
that it be converted to upper case in the HTTP message?
I guess that might actually
Anne van Kesteren wrote:
On Thu, 20 Apr 2006 23:38:56 +0200, Julian Reschke
[EMAIL PROTECTED] wrote:
In the end, we want to have these clients/libraries fixed, right?
I guess that's the question. Is it sensible to implement it as
case-sensitive knowing that you probably break content? (Such
Make it a SHOULD and twiddle your CR exit criteria to take it into
account; in the long term, implementations will sort themselves out.
The real danger here is that the WG will be tempted to use the API to
profile other parts of HTTP for convenience, or based on current
implementations,
On Apr 20, 2006, at 23:42, Mark Baker wrote:
I'm not aware of any HTTP extension methods which use a lower case
character, so why not make method case-insensitive, but prescribe
that it be converted to upper case in the HTTP message?
A few years back I implemented the server-side of an HTTP
On Apr 21, 2006, at 00:18, Mark Nottingham wrote:
Make it a SHOULD and twiddle your CR exit criteria to take it into
account; in the long term, implementations will sort themselves out.
My thoughts exactly.
The real danger here is that the WG will be tempted to use the API
to profile
On 4/20/06, Robin Berjon [EMAIL PROTECTED] wrote:
The real danger here is that the WG will be tempted to use the API
to profile other parts of HTTP for convenience, or based on current
implementations, as well. Please, don't.
Precisely. Anne raised concerns about exiting CR, but if we
On Fri, 21 Apr 2006, Robin Berjon wrote:
On Apr 21, 2006, at 00:18, Mark Nottingham wrote:
Make it a SHOULD and twiddle your CR exit criteria to take it into account;
in the long term, implementations will sort themselves out.
My thoughts exactly.
A specification that doesn't
Julian Reschke wrote:
Bizarre.
Why not just leave the value alone?
The value is atomized; the atom hashtable uses case-insensitive lookups.
-Boris
On Tue, 18 Apr 2006 17:05:48 +0200, Robin Berjon [EMAIL PROTECTED]
wrote:
If implementations are not case-sensitive for the method name, I would
say it really is bug and it needs to be fixed rather than ratified.
I tested in IE and FF. Both seems to be case-sensitive.
Cheers,
- Gorm
27 matches
Mail list logo
