Thanks!
Responses below -
On 2006/04/26, at 10:06 AM, Anne van Kesteren wrote:
Ack. BTW, the issues list isn't obviously linked from the WG's
home page.
It's right under Documents at http://www.w3.org/2006/webapi/ (first
hit for "issue") or did you mean the Member home page?
Argh. I so did not see that earlier :)
WRT URIs, what should happen when I pass it a URI with a
fragment identifier?
Do you perhaps know what implementations do?
I can't imagine that they'd do much, but I'll test and report
back. Assuming they don't, it might be good to say something to
the effect that fragment identifiers either
a) aren't allowed
b) might not be supported
Please e-mail your findings in a separate e-mail. Based on the
results we should probably be able to come up with some reasonable
requirements on UAs and authors...
Ack.
In HTTP, Content-* headers are entity headers -- they describe
properties of the content explicitly. As such, they're not
transparently handled by the implementations; if I send an entity
and it's got a gzip encoding, I expect the guy on the other side
to get a gzip encoding as well.
All that said, many people find it convenient for the
implementation to handle content-encoding automatically.
I think the implication of this is that *if* the WG decides that
content-encoding can be handled by the implementation
automatically, there should be some control offered to the user
over whether or not it happens.
The real trick for the WG might be in deciding what the default of
that control is.
Thanks, this makes it more clear. Are you willing to raise another
issue or should I do it? If you have more fancy tests available by
the way for this, they are welcome :-) The default probably has to
be based on what currently works.
I'll do it.
Yes. Something like "UAs that implement a cache should honour
request cache-control headers." Note the lower-case SHOULD; HTTP
already requires them to be honoured.
Based on my testing, implementations don't do this today. It would
be very good if they do; as it is, developers don't have any
control of the local cache.
Perhaps we can cover this in the testsuite?
That would work. Actually, that would be a way to help fix (or at
least notice) a lot of the underlying HTTP conformance problems
without causing implementations with problems to be considered non-
conformant to XHR, leading to CR problems...
[...]
The text reads as if persistent connection support is required,
when HTTP does not require it. It also normatively re-states the
requirements of HTTP, which isn't good specification practice.
Well, another way to set these headers is letting the author do it.
So I can see why there's a requirement on UAs here from that
perspective...
I was thinking of something like
"UAs must not allow the Content-Length, Connection or Keep-Alive
headers to be overridden."
instead of
"UAs must set the Connection and Keep-Alive headers as described by
the HTTP specification, and must not allow those headers to be
overridden."
because HTTP already tells UAs how to deal with these headers, and
they don't always have to set them.
Same sort of text for the Host header.
Also, add TE to the list of headers that UAs MAY add.
It MUST NOT be overriden?
Yes.
Cheers,
--
Mark Nottingham
[EMAIL PROTECTED]
