Re: [whatwg] Fetch: please review!
On Fri, Jun 7, 2013 at 8:15 PM, Rik Cabanier caban...@gmail.com wrote: http://fetch.spec.whatwg.org/#cors-same-origin contains the following: A response is either CORS-same-origin or CORS-cross-origin. Unless otherwise indicated a response is CORS-same-origin. but it doesn't say what the difference is between the two. The 'CO' in CORS stands for 'cross origin' so 'CORS-same-origin' would mean 'cross origin sharing for the same origin' which sounds a bit strange. I borrowed this terminology from the HTML standard. Since using these correctly in specifications requires detailed knowledge of origin-based security expanding on them didn't seem all too useful. I have been thinking about better terms. If we think about it in terms of classes, the base class would be Response. Most everything (apart from cookies/trailers, except maybe via special interfaces) is exposed here. Then there's TaintedResponse, what you get for img src=//crossorigin/. With the usual caveats for exporting from canvas and what not. And then there's CORSResponse for img src=//crossorigin/ crossorigin which has some limitations (e.g. on which headers are exposed by default), but much less than TaintedResponse. Moving towards that terminology would probably be a step up. I haven't quite convinced myself it's a 100% accurate and works across all specifications. Input welcome. -- http://annevankesteren.nl/
Re: [whatwg] Fetch: please review!
Hi Anne, Your specification contains the following [1]: A response is either CORS-same-origin or CORS-cross-origin. Unless otherwise indicated a response is CORS-same-origin. but it doesn't say what the difference is between the two. The 'CO' in CORS stands for 'cross origin' so 'CORS-same-origin' would mean 'cross origin sharing for the same origin' which sounds a bit strange. 1: http://fetch.spec.whatwg.org/#cors-same-origin On Wed, May 22, 2013 at 2:50 AM, Anne van Kesteren ann...@annevk.nl 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. -- http://annevankesteren.nl/
Re: [whatwg] Fetch: please review!
On Mon, May 27, 2013 at 1:24 AM, Peter Occil pocci...@gmail.com wrote: Step 7 of section 4.3 reads: Let headers be the names of request's author headers, sorted lexicographically and [[byte lowercased]]. Isn't the phrase byte lowercased rather easy to define, since each author header can only contain ASCII characters? Maybe it should be: 7. Let headers be the names of request's author headers. 7a. For each name in headers, convert that name to ASCII lowercase, and convert that name to a byte array by changing each code point to the corresponding byte. 7b. Sort headers in ascending order using a byte-for-byte comparison. Should not be too hard, indeed. However, the input is mostly likely an array of byte sequences. FTP Responses I have not looked into FTP yet. It's not an area that seems super important to get completely right. One issue box says Map the result to response. What exactly is the issue with mapping the result? Should the response, including errors, be mapped to HTTP responses somehow? Should FTP errors (4xx and 5xx) be treated as network errors? I'm not very familiar with FTP so this would basically require testing. E.g. can an FTP error still be accompanied by a resource as is possible for HTTP? HTTP 404 is not a network error and a HTTP 404 that comes with an image/png will display fine through img whereas a network error would not. Also, the text “Follow the requirements from FTP to retrieve a resource” is rather vague. It seems that’s because it takes more steps to retrieve a file via FTP than via HTTP. Implementations that don’t have a higher-level FTP backend may find it harder to understand what those steps consist of. Here is what I think are the steps. - Connect to server - If URL has username, send USER [username] - If URL has password, send PASS [password] - Send TYPE I (binary mode) - Send CWD [path] - Send RETR [filename] - Send QUIT Can we just reference the HTTP specification for this? I guess the URL username/password bit might not be covered? Moreover, if the FTP URL points to merely a directory, it’s unspecified what kind of resource should be returned. Maybe a list of files (LIST or NLST command)? What do user agents do today? -- http://annevankesteren.nl/
Re: [whatwg] Fetch: please review!
On Thu, May 23, 2013 at 9:33 AM, Simon Pieters sim...@opera.com wrote: Example (using backticks for code): I've done this, but I've not converted the components of a URL yet. I'm not sure if we should force those to be one or the other. I think strings might be the best even though most of the time they can be represented as byte sequences. And that's mostly because of the way the API works on URLs, but I would expect some more iteration here. (BTW should body be the empty byte string above?) Yes. -- http://annevankesteren.nl/
Re: [whatwg] Fetch: please review!
Step 7 of section 4.3 reads: Let headers be the names of request's author headers, sorted lexicographically and [[byte lowercased]]. Isn't the phrase byte lowercased rather easy to define, since each author header can only contain ASCII characters? Maybe it should be: 7. Let headers be the names of request's author headers. 7a. For each name in headers, convert that name to ASCII lowercase, and convert that name to a byte array by changing each code point to the corresponding byte. 7b. Sort headers in ascending order using a byte-for-byte comparison. - FTP Responses One issue box says Map the result to response. What exactly is the issue with mapping the result? Should the response, including errors, be mapped to HTTP responses somehow? Should FTP errors (4xx and 5xx) be treated as network errors? Also, the text “Follow the requirements from FTP to retrieve a resource” is rather vague. It seems that’s because it takes more steps to retrieve a file via FTP than via HTTP. Implementations that don’t have a higher-level FTP backend may find it harder to understand what those steps consist of. Here is what I think are the steps. - Connect to server - If URL has username, send USER [username] - If URL has password, send PASS [password] - Send TYPE I (binary mode) - Send CWD [path] - Send RETR [filename] - Send QUIT Moreover, if the FTP URL points to merely a directory, it’s unspecified what kind of resource should be returned. Maybe a list of files (LIST or NLST command)? --Peter
Re: [whatwg] Fetch: please review! (Anne van Kesteren)
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-requ...@lists.whatwg.org wrote: Send whatwg mailing list submissions to whatwg@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-requ...@lists.whatwg.org You can reach the person managing the list at whatwg-ow...@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 ann...@annevk.nl To: WHATWG wha...@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 ann...@annevk.nl To: WHATWG wha...@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.majn...@samsung.com To: whatwg@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
Re: [whatwg] Fetch: please review! (Anne van Kesteren)
On Fri, May 24, 2013 at 7:46 AM, alonisser a...@noal.org.il wrote: 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. It supplants a bunch of older specs, by way of centralizing the algorithms they all individual describe (or, in many cases, fail to describe). It won't break anything. The point is to have a single, easy to use description of how to fetch resources over the network, which can be used by other specs. Right now, most specs inadequately describe all the necessary details of their network activity, making it hard for implementors to converge on the same behavior. ~TJ
Re: [whatwg] Fetch: please review!
On Thu, 23 May 2013 07:11:45 +0200, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 22, 2013 at 12:20 PM, Janusz Majnert j.majn...@samsung.com wrote: 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. If you have a better way to do this, please do suggest. This problem has been introduced by HTTP and I think it's important to make sure we carefully distinguish between what are actually bytes and what are strings, while still maintaining the readability of Content-Type over expressing that as a sequence of hex numbers. Maybe say that for readability, byte strings are not written as hex numbers but as strings encoded as ASCII. Also, instead of distinguishing between the two by including or omitting quotes which seems subtle and hard to remember which is which, call out when something is a byte string rather than a string. Example (using backticks for code): [[ ↪ `about` If request's url's scheme data is `blank`, return a response whose headers consist of a single header whose name is the byte string `Content-Type` and value is the byte string `text/html;charset=utf-8`, and body is the empty string. Otherwise, return a network error. ]] (BTW should body be the empty byte string above?) -- Simon Pieters Opera Software
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 RD Institute Poland Samsung Electronics
Re: [whatwg] Fetch: please review!
On Wed, May 22, 2013 at 12:20 PM, Janusz Majnert j.majn...@samsung.com wrote: 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. If you have a better way to do this, please do suggest. This problem has been introduced by HTTP and I think it's important to make sure we carefully distinguish between what are actually bytes and what are strings, while still maintaining the readability of Content-Type over expressing that as a sequence of hex numbers. 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. Well, e.g. XMLHttpRequest has both and code points are quite distinct from bytes so it seemed useful to have them as distinct concepts. 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... Good call. * 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. Fixed both. Thanks! -- http://annevankesteren.nl/
