Re: [whatwg] What should the value attribute be for multi-file upload controls in WF2?
Adele Peterson wrote:
Hi all,
I'm looking at the Web Forms 2 specification for the multi-file upload
control that uses the min/max attributes. When multiple files are
selected, its unclear what the value attribute should contain. It could
contain just the first filename, or a comma separated list of all of the
filenames. I think it will be useful though to add something about this
in the specification for consistency.
Firefox 3 exposes an API that would let you get all filenames if
multiple files were selected. The .files property returns a (live) list
of file objects, each object has the following API:
interface DOMFile
{
readonly attribute DOMString fileName;
readonly attribute unsigned long long fileSize;
DOMString getAsText(in DOMString encoding);
DOMString getAsDataURL();
DOMString getAsBinary();
};
This of course doesn't answer the question of what to return for .value.
I would say return the first filename. Trying to encode all filenames in
a single string is just going to be more complicated than using the
above API, and returning an array is complicated API wise, and also
seems more complicated for users than using the above API.
/ Jonas
Re: [whatwg] TCPConnection feedback
(Sorry if this counts as thread necromancy. The discussion just didn't seem to have come to an end yet.) On Fri, Jun 20, 2008 at 3:55 PM, Frode Børli [EMAIL PROTECTED] wrote: I would manage, but i do not like the implementation (it is much more complex than it needs to be). I would basically hate doing extra work because the implementation wasnt good enough. It is worth spending months improving the implementation here, if it saves only one minute of work for each of the millions of web developers out there, in the future. Alright, point taken. You're of course absolutely right with that :) I agree, it would be very convenient to basically set up and control a web app in a single connection. However, I think there are valid use cases for just the opposite set up as well. So, if we use a HTTP handshake, we should provide two ways. If it is impossible to use HTML, then it is absolutely required that Session ID is added as a standard header - since that will be the only way of linking the generated HTML with the separate persistent connection. You can't assume that an application server or the web server will be able to parse the cookie, since the cookie format is different for each programming language/application. This depends on the layer where the session management takes place. For example, PHP's existing session handling system already uses cookies. So, a hypothetical future PPHP version of PHP could extend the session system to support this. This feature couldn't be implemented in the afromentioned few lines of perl though. If this feature is still wanted in a standardized way, I think the idea to have the server advertise that it wants to change the protocol but to let the client do the actual switch would be the best way. The HTTP 101 Switching Protocols can be sent by the server, without the client asking for a protocol change. The only requirement is that the server sends 426 Upgrade Required first, then specifies which protocol to switch to. The protocol switched to could possibly be the one proposed in the beginning of this thread. I don't see how we could use 426 as a notification that the client should open a WebSocket connection. 426 is still an error code, so if you send it as the reply to the initial GET request, you can't be sure the HTML file you pushed gets interpreted the correct way. While this would probably work, it would be semantically unclean at best. However, the TLS -over-HTTP spec states As specified in HTTP/1.1, the server MAY include an Upgrade header in any response other than 101 or 426 to indicate a willingness to switch to any (combination) of the protocols listed. http://www.ietf.org/rfc/rfc2817.txt I can't seem to find any mention about this in the HTTP spec though. Is this implemented or at least widely known? Maybe you could reasoneably assume that a proxy keeps a connection open if an upgrade seems imminent? If this works, we could extend Michael's original algorithm as follows (this would be in addition to the new WebSocket() interface and would not replace it) PROPOSAL: Turning an existing HTTP connection into a WebSocket connection: If the server sends a Connection: Upgrade header and an Upgrade header with a WebSocket token as part of a normal response and if the resource fetched established a browsing contest, the client must not issue any other requests on that connection and must initiate a protocol switch. After the switch has finished, the client would expose the connection to the application via a DefaultWebSocket property or something similar. An exchange could look like this: C: GET /uri HTTP/1.1 C: Host: example.com C: [ ... usual headers ... ] C: S: HTTP/1.1 200 OK S: Content-Type: text/html S: [ ... usual headers ... ] S: Upgrade: WebSocket/1.0 S: Connection: Upgrade S: S: [ ... body ... ] C: OPTIONS /uri HTTP/1.1 C: Host: example.com C: Upgrade: WebSocket/1.0 C: Connection: Upgrade C: S: HTTP/1.1 101 Switching Protocols S: Upgrade: WebSocket/1.0 S: Connection: Upgrade S: C/S: [ ... application specific data ... ] Because the connection would be same-origin pretty much per definition, no access checks would be needed in that situation. Would something like this be doable and wanted? On Fri, Jun 20, 2008 at 1:52 PM, Frode Børli [EMAIL PROTECTED] wrote: I have a proposal for a cross domain security framework that i think should be implemented in browsers, java applets, flash applets and more. If we use any kind of verification that happens outside the connections, we should at least a hint inside the connection, which host the browser wants to connect though. I think raw TCP connections would cause major security holes with shared hosts, even if cross-domain connections need a DNS record. Yes, if we are using the WebSocket - but not if using the TCP connection. Nobody will be allowed to run a separate application that listens on a port on a shared server anyway. Consider the following scenario:
[whatwg] Canvas tests updated
I've recently updated my canvas tests at http://philip.html5.org/tests/canvas/suite/tests/ so they ought to be up-to-date with the latest version of the spec, and have greater coverage than before. (Text rendering is the only thing that's intentionally untested, though I may have missed some other smaller areas.) http://philip.html5.org/tests/canvas/suite/tests/results.html shows the results I got from testing various browsers. Using the totally unfair unrepresentative biased method of counting the number of passes, the latest versions of Opera and WebKit and Konqueror are roughly tied in first place while Firefox is last (except for IE which doesn't really count), but even the best fail about a quarter of the tests, so there's plenty of scope for bug-fixing :-) Anyway, it's quite likely that a number of the tests are incorrect, since nobody (including me) has reviewed them carefully; or that the tests are correct according to the spec but the spec is incorrect according to reality; so it would be good to get feedback from anyone who notices issues in them. -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] TCPConnection feedback
It is worth spending months improving the implementation here, if it saves only one minute of work for each of the millions of web developers out there, in the future. Alright, point taken. You're of course absolutely right with that :) I agree, it would be very convenient to basically set up and control a web app in a single connection. However, I think there are valid use cases for just the opposite set up as well. So, if we use a HTTP handshake, we should provide two ways. Agree If it is impossible to use HTML, then it is absolutely required that Session ID is added as a standard header - since that will be the only way of linking the generated HTML with the separate persistent connection. You can't assume that an application server or the web server will be able to parse the cookie, since the cookie format is different for each programming language/application. This depends on the layer where the session management takes place. For example, PHP's existing session handling system already uses cookies. So, a hypothetical future PPHP version of PHP could extend The PHP *script* decides how to encode session identifiers, not the PHP-engine. PHP has a default cookie variable called PHPSESSID that many php-scripts use but many PHP-applications implement their own session handling. If the Session ID was implemented trough headers, it would have the following benefits: 1. Many more links in the chain between the browser and the server side script can utilize session id; for example a load balancer will easily see which internal server to pass requests to. 2. Session ID is not available for client side scripts - and makes session hijacking much more difficult. (Today they are accessible trough document.cookie) 3. Server side logic can be implemented in many more layers for connecting requests to an actual user session. 4. Statistics tools can much more easily identify unique visitors, as Session ID potentially could be logged in log files. I am sure there are more advantages. the session system to support this. This feature couldn't be implemented in the afromentioned few lines of perl though. SessionID header only need to be implemented on the client side for HTML5 browsers. Server side scripting languages can immediately read headers and set headers - but it would be an advantage if PHP (and others) was updated to use SessionID-header as default for request from browsers supporting HTML5. The HTTP 101 Switching Protocols can be sent by the server, without the client asking for a protocol change. The only requirement is that the server sends 426 Upgrade Required first, then specifies which protocol to switch to. The protocol switched to could possibly be the one proposed in the beginning of this thread. I don't see how we could use 426 as a notification that the client should open a WebSocket connection. 426 is still an error code, so if you send it as the reply to the initial GET request, you can't be sure the HTML file you pushed gets interpreted the correct way. While this would probably work, it would be semantically unclean at best. I am not a HTTP protocol wizard, but I have read that something similar is done for starting HTTPS-communications, and I believe the same procedure can be used for WebSocket. PROPOSAL: Turning an existing HTTP connection into a WebSocket connection: If the server sends a Connection: Upgrade header and an Upgrade header with a WebSocket token as part of a normal response and if the resource fetched established a browsing contest, the client must not issue any other requests on that connection and must initiate a protocol switch. After the switch has finished, the client would expose the connection to the application via a DefaultWebSocket property or something similar. An exchange could look like this: C: GET /uri HTTP/1.1 C: Host: example.com C: [ ... usual headers ... ] C: S: HTTP/1.1 200 OK S: Content-Type: text/html S: [ ... usual headers ... ] S: Upgrade: WebSocket/1.0 S: Connection: Upgrade S: S: [ ... body ... ] C: OPTIONS /uri HTTP/1.1 C: Host: example.com C: Upgrade: WebSocket/1.0 C: Connection: Upgrade C: S: HTTP/1.1 101 Switching Protocols S: Upgrade: WebSocket/1.0 S: Connection: Upgrade S: C/S: [ ... application specific data ... ] Because the connection would be same-origin pretty much per definition, no access checks would be needed in that situation. Would something like this be doable and wanted? This is exactly what I was trying to describe :) Consider the following scenario: Bob and Eve have bought space on a run-of-the-mill XAMPP web hoster. They have different domains but happen to be on the same IP. Now Eve wants do bruteforce Bob's password-protected web application. So she adds a script to her relatively popular site that does the following: So Bob will DDOS his own server? And my proposals allows using hostnames OR ip-addresses in the DNS TXT record, so unless Eve
Re: [whatwg] What should the value attribute be for multi-fileupload controls in WF2?
Because it breaks the common interface that the value property returns a scalar? Doesn't renaming the .value property to for example .files also break the common interface? Frode
Re: [whatwg] What should the value attribute be formulti-fileupload controls in WF2?
Breaking the interface means changing the semantics without introducing new syntax. For example, if x is int[10] and you decide you need 20 of them afterwards, you say x2 is int[20] and you throw x away. Afterwards you have to accommodate the code using x, which is now undefined, to the new semantics. The fact that x is undefined is helpful because you have a smaller chance of overlooking something. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frode Borli Sent: Tuesday, June 24, 2008 10:41 PM To: Kristof Zelechovski Cc: [EMAIL PROTECTED]; Thomas Broyer Subject: Re: [whatwg] What should the value attribute be formulti-fileupload controls in WF2? Because it breaks the common interface that the value property returns a scalar? Doesn't renaming the .value property to for example .files also break the common interface? Frode
