Hi!
I specifically submitted to this list to discuss this issue. I'm by no
means a web standards expert so if I'm simply reading the specs wrong
please let me know.
Executive summary:
The current specs clearly say that XMLHttpRequest responses without a
Content-Type header are to be treated as
On Fri, 15 Jun 2007 07:58:30 +0200, Carsten Orthbandt
[EMAIL PROTECTED] wrote:
Executive summary:
The current specs clearly say that XMLHttpRequest responses without a
Content-Type header are to be treated as text/plain, not XML. There's
a change underway that says that such content should
Anne van Kesteren schrieb:
We have to deal with reality. This change was made to the specification
because UA implementors already populate responseXML with a parsed
document if the response does not include a Content-Type header and said
they could not remove that. If you can convince UA
Carsten Orthbandt [EMAIL PROTECTED]
- If the XMLHttpRequest response does not specify a Content-Type, scan it
for
the xml signature and ONLY parse as XML if it [was] found.
- Do NOT log errors for parsing errors when no Content-Type was given
Logging of errors is something that should be
* Carsten Orthbandt wrote:
Bjoern Hoehrmann schrieb:
Why don't you use less , , and ]] sequences in the content and wrap
it into x.../x?
If my response body is (literal example)
---snip---
ut:7325
ubc:0
---snap---
there's obviously some hesitation to wrap that as
---snip---
?xml
Julian Reschke schrieb:
You're violating a SHOULD level requirement of HTTP/1.1 then. Sorry, but
that's what you get for that :-).
- I definately dont want to see future browsers choke on that
Actually, I'm tempted to say it would be good for the web if more UAs
would flag missing
Jim Ley schrieb:
Logging of errors is something that should be entirely down to the
application, there is no need for the spec to require certain things be
logged in an error console or not - or even the existence of an error
console - whilst I'm very sympathetic for your desire to make
Bjoern Hoehrmann schrieb:
Why don't you use less , , and ]] sequences in the content and wrap
it into x.../x?
If my response body is (literal example)
---snip---
ut:7325
ubc:0
---snap---
there's obviously some hesitation to wrap that as
---snip---
?xml version=1.0?
x
ut:7325
ubc:0
/x
Carsten Orthbandt wrote:
Julian Reschke schrieb:
You're violating a SHOULD level requirement of HTTP/1.1 then. Sorry, but
that's what you get for that :-).
- I definately dont want to see future browsers choke on that
Actually, I'm tempted to say it would be good for the web if more UAs
Carsten Orthbandt wrote:
...
My wording here was probably unclear. My intent is not to have the spec
define how or when an UA should report errors. I'd like the spec to define
what is an actual error in the processing and what are merely different
execution paths of the algorithms laid out.
Julian Reschke [EMAIL PROTECTED]
I have to agree here. If a recipient decides to do content-type guessing,
the fact that the type is not what was tested is not an error. One more
reason not to guess in the first place.
But it might be what's tested just invalid - if the user expected the
Jim Ley wrote:
Julian Reschke [EMAIL PROTECTED]
I have to agree here. If a recipient decides to do content-type
guessing, the fact that the type is not what was tested is not an
error. One more reason not to guess in the first place.
But it might be what's tested just invalid - if the user
Jim Ley schrieb:
(off list?)
Sorry, hit the wrong reply button...
Carsten Orthbandt [EMAIL PROTECTED]
Jim Ley schrieb:
The HTTP default content type (octet stream) is actually exactly
the type it is: an opaque data stream not meant to be interpreted.
No, don't agree at all with vnd.
I don't want to let loose a big discussion about best practices
here. The issue at hand is certainly solvable on our side.
But I do see a problem here with changing the spec in a way that
obviously breaks old apps that were fully standards compliant.
Sending a content type header was NOT
The specification is still in development. That you considered it stable
is an error on your side, unfortunately.
Yes. But then there's reality...
Following that argument you could as well completely change the meaning of the
readyState field and expect the rest of the world to happily accept
On Fri, 15 Jun 2007 11:17:32 +0200, Carsten Orthbandt
[EMAIL PROTECTED] wrote:
The specification is still in development. That you considered it stable
is an error on your side, unfortunately.
Yes. But then there's reality...
The reality required the specification to change.
Following
Carsten Orthbandt wrote:
I don't want to let loose a big discussion about best practices
here. The issue at hand is certainly solvable on our side.
But I do see a problem here with changing the spec in a way that
obviously breaks old apps that were fully standards compliant.
There is no
On Fri, 15 Jun 2007 10:56:19 +0200, Carsten Orthbandt
[EMAIL PROTECTED] wrote:
I don't want to let loose a big discussion about best practices
here. The issue at hand is certainly solvable on our side.
But I do see a problem here with changing the spec in a way that
obviously breaks old apps
Bjoern Hoehrmann wrote:
* Carsten Orthbandt wrote:
Bjoern Hoehrmann schrieb:
Why don't you use less , , and ]] sequences in the content and wrap
it into x.../x?
If my response body is (literal example)
---snip---
ut:7325
ubc:0
---snap---
there's obviously some hesitation to wrap that as
Anne van Kesteren schrieb:
The reality required the specification to change.
Just out of curiosity, would you care to elaborate on this?
It's not a serious change. It's how XMLHttpRequest works in the real
world. The reason Firefox 3 shows errors in the error console and
Firefox 2 does
Anne van Kesteren schrieb:
The specification once had a concept of what is and what is not
conforming for scripts to do, but it was to much of a hassle so that has
been dropped. Whether or not user agents show an error message is up to
them really.
So basically we're back to square one and
On Fri, 15 Jun 2007 12:08:06 +0200, Carsten Orthbandt
[EMAIL PROTECTED] wrote:
If the spec clearly said if there is no Content-Type specified, the
UA should try to treat it as XML, but not raise any error conditions
if parsing fails there would be no compatibility issues and the
behaviour of
Carsten Orthbandt wrote:
The (IMHO) valid reason here is:
- redundant header overhead
- the UA isn't even meant to interpret the response, so it doesn't need
any information on how to parse it
Actually, you're expecting the UA to convert the bytes in the response into
characters in this
Boris Zbarsky schrieb:
Carsten Orthbandt wrote:
The (IMHO) valid reason here is:
- redundant header overhead
- the UA isn't even meant to interpret the response, so it doesn't need
any information on how to parse it
Actually, you're expecting the UA to convert the bytes in the response
Carsten Orthbandt [EMAIL PROTECTED] wrote:
It's obviously no big deal to re-add [Content-Type headers]. The point is
that all available material said that stripping Content-Type would be fine
and in fact it was. Now it's not and I suspect that we are not the only
ones to get bitten by it. A
25 matches
Mail list logo
