On Fri, 13 Sep 2013 12:32:43 +0200, Robin Berjon <ro...@w3.org> wrote:
On 29/08/2013 15:58 , Simon Pieters wrote:
On Thu, 29 Aug 2013 15:02:48 +0200, Anne van Kesteren <ann...@annevk.nl>
wrote:
On Thu, Aug 29, 2013 at 1:19 PM, Jake Archibald
<jaffathec...@gmail.com> wrote:
Causing a network error in existing browsers is a shame.
It seems to fail to resolve in IE10. It works in
Gecko/WebKit/Blink/Presto: the %! is requested literally. However, both
Apache and IIS seems to return 400 Bad Request.
That's not exactly promising.
Picking something that could occur in paths seems problematic.
I'm not sure why it's more problematic than something than could occur
in the fragment.
For instance, the string "$zip=" is not present at all in
http://webdevdata.org/ data set 18/06/2013. So maybe we could use a
string like that in the path and have a graceful fallback path in legacy
browsers that work in existing servers.
That's my preferred approach so far. However I wonder about the precise
details.
Assuming <img src="/foo.zip/$zip=dahut.png"> I'm guessing that the
browser would actually just request "/foo.zip" from the server in the
same manner that fragments are stripped, right?
"/foo.zip/", but yeah.
Somehow the stripping bothers me a bit; for instance, what would
Navigation Controller see?
I'm not familiar with that.
I wonder if we couldn't just use the query part for this: <img
src="/foo.zip?!zip/dahut.png">. No stripping is needed (as far as I know
servers would normally just serve foo.zip in this case), which
simplifies the model.
The query is sent to the server. What the server does with it depends on
the server. Making different requests for /foo.zip?!zip/dahut.png and
/foo.zip?!zip/lol.png is bad because we want the same response for UAs
that support the feature, but caches wouldn't know that they're the same
when they have different queries.
--
Simon Pieters
Opera Software
