W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Fetch: please review!

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 5 Jun 2013 14:02:47 +0100
Message-ID: <CADnb78hyAOK0iHseYaeV_ap9__SxhdYF2aEqDVS7cUc1K26SQw@mail.gmail.com>
To: Peter Occil <poccil14@gmail.com>
Cc: WHATWG <whatwg@lists.whatwg.org>
On Mon, May 27, 2013 at 1:24 AM, Peter Occil <poccil14@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?

Received on Wednesday, 5 June 2013 13:03:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:00 UTC