[whatwg] Fetch: please review! (Anne van Kesteren)

[alonisser]

some input (I know, I'm a newbie in this mailing list so maybe i'm stating
or asking the obvious, atleast for everyone else):

   1. for clarity: The legacy chapter should be near the end and not the
   first chapter, I couldn't understand most of it because it uses terminology
   from the Fetch Standard, explained later.
   2.  What is the purpose of fetch standard?  replacing http/html
   requests? something else? yes I read:

   To unify fetching across the web platform this specification supplants a
   number of algorithms and specifications:

   but I'm not sure what does that means. since this is a big change,
    changing the way tjhat all clients and web servers work (maybe this is why
   the legacy part is so early in the doc? because almost all the web is
   legacy?)

   looks to me like something that could be breaking the web (xhtml 2.0
   anyone) And I'm not sure for what benefit? some new url schemes? a more
   correct and rational http fetch behavior? we already got used the the
   current behavior. changing this should come with a very good reason. if
   anything. The rational for "Fetch" should come before anything else.

Thanks for the chance to input on this
Alon Nisser



On Wed, May 22, 2013 at 10:06 PM, <whatwg-request at lists.whatwg.org> wrote:

> Send whatwg mailing list submissions to
>         whatwg at lists.whatwg.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
> or, via email, send a message with subject or body 'help' to
>         whatwg-request at lists.whatwg.org
>
> You can reach the person managing the list at
>         whatwg-owner at lists.whatwg.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of whatwg digest..."
>
> When replying to digest messages, please please PLEASE update the subject
> line so it isn't the digest subject line.
> Today's Topics:
>
>    1. Reorganizing and fixing "origin" (Anne van Kesteren)
>    2. Fetch: please review! (Anne van Kesteren)
>    3. Re: Fetch: please review! (Janusz Majnert)
>
>
> ---------- Forwarded message ----------
> From: Anne van Kesteren <annevk at annevk.nl>
> To: WHATWG <whatwg at whatwg.org>
> Cc:
> Date: Wed, 22 May 2013 08:53:13 +0100
> Subject: [whatwg] Reorganizing and fixing "origin"
> As Björn points out in
> http://www.ietf.org/mail-archive/web/websec/current/msg01512.html
> defining origin of a URL in terms of STD66 is broken. So we should
> define it in terms of the URL Standard.
>
> The Origin header also has problems, as it suggests you can have a
> space-separated list, which we disallowed almost immediately after the
> Origin RFC was published and the IETF group did not accept errata for.
>
> Now "Origin of a URL" can be defined in the URL Standard (not done
> yet). I put an updated definition of the header here:
> http://fetch.spec.whatwg.org/#http-origin-header
>
> Where should we put the definition of origin itself? Back in HTML? I
> guess it still is mostly.
>
>
> --
> http://annevankesteren.nl/
>
>
>
> ---------- Forwarded message ----------
> From: Anne van Kesteren <annevk at annevk.nl>
> To: WHATWG <whatwg at whatwg.org>
> Cc:
> Date: Wed, 22 May 2013 10:50:37 +0100
> Subject: [whatwg] Fetch: please review!
> I'm reaching the point where I want to start integrating
> http://fetch.spec.whatwg.org/ into http://xhr.spec.whatwg.org/ so I
> can remove a lot of the duplicate requirements with respect to
> networking and at the same time clarify a lot of the networking
> behavior.
>
> And although http://fetch.spec.whatwg.org/ is pretty dry reading it
> would be good if people could take a look at it as the idea is for it
> to define the fetching behavior across the platform. This task is
> currently divided between HTML, CORS, Web Origin Concept, and CSP
> (integration hooks not yet in Fetch) and creates a real messy
> situation for specifications building on top of them. The idea is to
> remove that complexity and have a simple hook for fetching a request
> and get a response in return.
>
>
> --
> http://annevankesteren.nl/
>
>
>
> ---------- Forwarded message ----------
> From: Janusz Majnert <j.majnert at samsung.com>
> To: whatwg at lists.whatwg.org
> Cc:
> Date: Wed, 22 May 2013 13:20:13 +0200
> Subject: Re: [whatwg] Fetch: please review!
> Hi,
>
> On 2013-05-22 11:50, Anne van Kesteren wrote:
>
>> I'm reaching the point where I want to start integrating
>> http://fetch.spec.whatwg.org/ into http://xhr.spec.whatwg.org/ so I
>> can remove a lot of the duplicate requirements with respect to
>> networking and at the same time clarify a lot of the networking
>> behavior.
>>
>> And although http://fetch.spec.whatwg.org/ is pretty dry reading it
>> would be good if people could take a look at it as the idea is for it
>> to define the fetching behavior across the platform. This task is
>> currently divided between HTML, CORS, Web Origin Concept, and CSP
>> (integration hooks not yet in Fetch) and creates a real messy
>> situation for specifications building on top of them. The idea is to
>> remove that complexity and have a simple hook for fetching a request
>> and get a response in return.
>>
>>
> I have a few notes to make on the use of "byte string" notion.
> First of all, let's look at the definition of "byte string":
> "A byte string is a byte sequence written down as a string."
> Where "byte" and "string" are:
> "A byte is a sequence of eight bits, represented as a double-digit
> hexadecimal number in the range 0x00 to 0xFF."
> "A string is a sequence of code points." and later "A code point is a
> Unicode code point and is represented as a four-to-six digit hexadecimal
> number, typically prefixed with "U+"."
>
> So, just by looking at the definition, I would expect a byte string to be
> a sequence of hex numbers. That is of course not what is put in the
> examples and not what this definition aimed for.
>
> The second note is more of a question: why is the "byte string" even used?
> Why not use just string? The document contains just one occurrence of plain
> "string" and could very well be replaced with a byte string.
>
> And now for some things I think are errors:
> * in section "4.5 CORS check", point 4 reads "If request's origin
> serialized to bytes is not result, return failure." I think it should be
> "...serialized to byte string..."
> * in section "4.1 Basic fetch", "about" bullet reads: "... header whose
> name is Content-Type and value is "text/html;charset=utf-8", and...". I
> think, as the value of a header is defined to be a byte string, that there
> should be no quotation marks around text/html;charset=utf-8.
>
>
> Best regards,
> Janusz Majnert
> Samsung R&D Institute Poland
> Samsung Electronics
>
>
>
> _______________________________________________
> whatwg mailing list
> whatwg at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org
>
>