[cors] Case-sensitive matching of origin URLs?

[Vladimir Dzhuvinov]

Hi,

I'm writing a generic Java servlet filter to implement the current
CORS draft. I'm confused about the correct way to check if a reported
Origin is allowed by the resource's allow list.

The Origin spec, which the CORS draft refers to, implies that 2
origins are equal if they match, regardless of their case (upper or
lower):

http://tools.ietf.org/html/draft-abarth-origin-07



The CORS draft on the other hand requires case-sensitive matching of origins:

http://www.w3.org/TR/access-control/#resource-requests


Please, advise.

Vladimir
-- 
Vladimir Dzhuvinov :: software.dzhuvinov.com

Re: [cors] Case-sensitive matching of origin URLs?

[Anne van Kesteren]

On Thu, 23 Sep 2010 08:40:42 +0200, Vladimir Dzhuvinov  
 wrote:
The CORS draft on the other hand requires case-sensitive matching of  
origins:


http://www.w3.org/TR/access-control/#resource-requests


It requires case-sensitive matching of the serialization of origins. They  
are never parsed into origins to begin with.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [IndexedDB] A "versionchangeblocked" event

[Jeremy Orlow]

Are we really sure this is needed?

I was just writing up a bug for this and started to wonder if we needed any
event when there no longer is a block.  I then realized that once you're
unblocked the onsuccess should fire immediately, so there's no need.  But
wait...isn't this true of normal blocking as well?  Basically either the
onsuccess will fire immediately or onblocked will.  So couldn't an app just
assume it's blocked until it receives a onsuccess message?  The worst case
is that the web app blinks up some message to the user to close other
windows, but it seems like that could happen even with an onblocked event
being added.  Am I missing something here?

J

On Thu, Sep 23, 2010 at 9:57 PM, ben turner  wrote:

> I'm voting for 1! I'd hate to give all the other requests a property
> that only setVersion requests will use.
>
> -Ben
>
> On Thu, Sep 23, 2010 at 9:48 AM, Jonas Sicking  wrote:
> > On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow 
> wrote:
> >> On Wed, Sep 22, 2010 at 9:07 PM, ben turner 
> wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> While implementing the latest setVersion changes Jonas and I decided
> >>> that it would be really useful to be able to signal to the caller that
> >>> other web pages are open and using the database (thus preventing a
> >>> setVersion transaction from running).
> >>>
> >>> Consider a web page open in two windows, one minimized or otherwise
> >>> obscured and the other in the foreground. If the background window is
> >>> running a transaction then the foreground window will not be able to
> >>> immediately begin a setVersion transaction when it makes that request.
> >>> The spec currently informs the background page that it should close
> >>> all its databases, but it would be even more useful to inform the
> >>> foreground page that it is currently blocked. That way the foreground
> >>> page could display some kind of notification ("Hey, you! Go close your
> >>> other tabs if you want us to upgrade the database!") that would aid
> >>> the process. We are also relying on page authors to correctly call
> >>> close() on their databases in response to the "versionchanged" event
> >>> and I don't believe that they will always follow through.
> >>>
> >>> Jonas and I thought of three possibilities:
> >>>
> >>> 1. Make setVersion return a special kind of request that had an
> >>> "onblocked" event handler. The caller could then add a handler just as
> >>> they do for success and error conditions.
> >>> 2. Make all IDBRequests have an "onblocked" handler, but just never
> >>> call it in other situations.
> >>> 3. Fire a "versionchangeblocked" event at the database.
> >>>
> >>> What do you guys think? Any preferences? I don't really like 2, and
> >>> I've preemptively implemented 3, but I'm not in love with 1 or 3
> >>> either.
> >>
> >> This exact thing came up when we originally talked about setVersion.  I
> >> thought Jonas proposed and we decided on 1 (though I'm not against 3)..?
> >>  Did this just not make it into the spec?
> >
> > I think that 1 and 2 are the best solutions and I too thought that
> > that was what we had decided on. I don't really see the advantage with
> > 3 since it means that you have to register event handlers on two
> > separate objects, and potentially worry about colliding with other
> > pieces of code doing version upgrades (though the latter problem seems
> > somewhat far fetched).
> >
> > IMHO 2 seems simpler but I don't really care between 1 and 2. I'll
> > note that there is lots of precedence in the HTML5 spec of adding
> > attribute handlers on objects even though they don't necessarily fire
> > on the given object. This was done to keep down the number of
> > interfaces and thus keep things simpler.
> >
> > But if people prefer 1 I'm game for that too.
> >
> > / Jonas
> >
>

Re: [cors] Case-sensitive matching of origin URLs?

[Vladimir Dzhuvinov]

>> The CORS draft on the other hand requires case-sensitive matching of
>> origins:
>>
>> http://www.w3.org/TR/access-control/#resource-requests
>
> It requires case-sensitive matching of the serialization of origins. They
> are never parsed into origins to begin with.

Does this mean that the value of the origin header should be treated
as an arbitrary string?

Because if I don't parse the origin value I have no mean of knowing
that it actually represents a valid origin.

Vladimir
--
Vladimir Dzhuvinov :: software.dzhuvinov.com

[CORS] Multiple origin values?

[Vladimir Dzhuvinov]

Another question regarding the CORS spec:

1. Why would a browser report multiple Origins to the web server?

2. http://www.w3.org/TR/access-control/#resource-requests  Why does
the spec prescribe "match any" instead of "match all" when multiple
origin values are received? Shouldn't the server app determine whether
AND or OR matching is more appropriate?


Vladimir

-- 
Vladimir Dzhuvinov :: software.dzhuvinov.com

Re: [IndexedDB] A "versionchangeblocked" event

[ben turner]

The strategy we decided on was to send a 'versionchange' event to
every database that isn't closed first. Then we loop again and if
there are any left that are not closed we fire the blocked event.
Since we expect pages to call close() inside their 'versionchange'
handler we shouldn't be firing the blocked event unless it's really
necessary.

-Ben

On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow  wrote:
> Are we really sure this is needed?
> I was just writing up a bug for this and started to wonder if we needed any
> event when there no longer is a block.  I then realized that once you're
> unblocked the onsuccess should fire immediately, so there's no need.  But
> wait...isn't this true of normal blocking as well?  Basically either the
> onsuccess will fire immediately or onblocked will.  So couldn't an app just
> assume it's blocked until it receives a onsuccess message?  The worst case
> is that the web app blinks up some message to the user to close other
> windows, but it seems like that could happen even with an onblocked event
> being added.  Am I missing something here?
> J
> On Thu, Sep 23, 2010 at 9:57 PM, ben turner  wrote:
>>
>> I'm voting for 1! I'd hate to give all the other requests a property
>> that only setVersion requests will use.
>>
>> -Ben
>>
>> On Thu, Sep 23, 2010 at 9:48 AM, Jonas Sicking  wrote:
>> > On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow 
>> > wrote:
>> >> On Wed, Sep 22, 2010 at 9:07 PM, ben turner 
>> >> wrote:
>> >>>
>> >>> Hi folks,
>> >>>
>> >>> While implementing the latest setVersion changes Jonas and I decided
>> >>> that it would be really useful to be able to signal to the caller that
>> >>> other web pages are open and using the database (thus preventing a
>> >>> setVersion transaction from running).
>> >>>
>> >>> Consider a web page open in two windows, one minimized or otherwise
>> >>> obscured and the other in the foreground. If the background window is
>> >>> running a transaction then the foreground window will not be able to
>> >>> immediately begin a setVersion transaction when it makes that request.
>> >>> The spec currently informs the background page that it should close
>> >>> all its databases, but it would be even more useful to inform the
>> >>> foreground page that it is currently blocked. That way the foreground
>> >>> page could display some kind of notification ("Hey, you! Go close your
>> >>> other tabs if you want us to upgrade the database!") that would aid
>> >>> the process. We are also relying on page authors to correctly call
>> >>> close() on their databases in response to the "versionchanged" event
>> >>> and I don't believe that they will always follow through.
>> >>>
>> >>> Jonas and I thought of three possibilities:
>> >>>
>> >>> 1. Make setVersion return a special kind of request that had an
>> >>> "onblocked" event handler. The caller could then add a handler just as
>> >>> they do for success and error conditions.
>> >>> 2. Make all IDBRequests have an "onblocked" handler, but just never
>> >>> call it in other situations.
>> >>> 3. Fire a "versionchangeblocked" event at the database.
>> >>>
>> >>> What do you guys think? Any preferences? I don't really like 2, and
>> >>> I've preemptively implemented 3, but I'm not in love with 1 or 3
>> >>> either.
>> >>
>> >> This exact thing came up when we originally talked about setVersion.  I
>> >> thought Jonas proposed and we decided on 1 (though I'm not against
>> >> 3)..?
>> >>  Did this just not make it into the spec?
>> >
>> > I think that 1 and 2 are the best solutions and I too thought that
>> > that was what we had decided on. I don't really see the advantage with
>> > 3 since it means that you have to register event handlers on two
>> > separate objects, and potentially worry about colliding with other
>> > pieces of code doing version upgrades (though the latter problem seems
>> > somewhat far fetched).
>> >
>> > IMHO 2 seems simpler but I don't really care between 1 and 2. I'll
>> > note that there is lots of precedence in the HTML5 spec of adding
>> > attribute handlers on objects even though they don't necessarily fire
>> > on the given object. This was done to keep down the number of
>> > interfaces and thus keep things simpler.
>> >
>> > But if people prefer 1 I'm game for that too.
>> >
>> > / Jonas
>> >
>
>

Re: [CORS] Multiple origin values?

[Anne van Kesteren]

On Fri, 24 Sep 2010 16:31:52 +0200, Vladimir Dzhuvinov  
 wrote:

Another question regarding the CORS spec:

1. Why would a browser report multiple Origins to the web server?


Redirects.



2. http://www.w3.org/TR/access-control/#resource-requests  Why does
the spec prescribe "match any" instead of "match all" when multiple
origin values are received? Shouldn't the server app determine whether
AND or OR matching is more appropriate?


The server can pretty much do whatever it wants, but if it does not do  
what is described here there would be a security vulnerability.



--
Anne van Kesteren
http://annevankesteren.nl/

[Bug 9989] Is the number of replacement characters supposed to be well-defined? If not this should be explicitly noted. If it is then more detail is required.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9989


Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||NEEDSINFO




--- Comment #6 from Ian 'Hixie' Hickson   2010-09-24 14:56:48 ---
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 5

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[CORS] Access-Control-Expose-Headers

[Vladimir Dzhuvinov]

Regarding the CORS spec:

Shouldn't "list of exposed headers" be added to the resource policy
bullet list? Or is that already covered by "list of supported
headers"?

http://www.w3.org/TR/access-control/#resource-processing-model

-- 
Vladimir Dzhuvinov :: software.dzhuvinov.com

Re: [DOMCore] Attr

[Alexey Proskuryakov]

11.09.2010, в 21:17, Michael A. Puls II написал(а):

> At the time, I made  
> to test some things with Attr nodes. (Note that the description on that page 
> is outdated.)

A few days ago, I fixed some aspects of Attr behavior in WebKit, here's a test 
I made: 
.
 Opera pretty much passes it, with the minor exception of 
Attr.firstChild.splitText() not splitting the text node.

- WBR, Alexey Proskuryakov

Re: Request for Comments: view-mode Media Feature test cases

[Brad Kemper]

I was looking at the spec, and it has "minimized" spelled two different ways:

minimized
Describes a Web application docked or otherwise minimised...

On Sep 24, 2010, at 8:47 AM, Arthur Barstow wrote:

> 
> Hi All,
> 
> Opera's participants in the WebApps WG have completed a test suite for the 
> 24-June-2010 'view-mode' Media Feature Candidate Recommendation [CR]. Given 
> this spec's dependency on Media Queries, we would appreciate feedback from 
> the CSS community on the test cases, which can be found by following the 
> "Show all tests" link at:
> 
>  http://dev.w3.org/2006/waf/widgets-vmmf/test-suite/#product-ua
> 
> Note the test suite only covers the Widget [Widget] use case.
> 
> If you have any comments, please send them to the following mail list by the 
> end of October:
> 
>  public-webapps@w3.org
> 
> -Regards, Art Barstow
> 
> [CR] http://www.w3.org/TR/2010/CR-view-mode-20100624/
> [Widget] http://www.w3.org/TR/widgets/#abstract
> 
> 
> 
> 
> 

Re: [IndexedDB] A "versionchangeblocked" event

[Jonas Sicking]

On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow  wrote:
> Are we really sure this is needed?
> I was just writing up a bug for this and started to wonder if we needed any
> event when there no longer is a block.  I then realized that once you're
> unblocked the onsuccess should fire immediately, so there's no need.  But
> wait...isn't this true of normal blocking as well?  Basically either the
> onsuccess will fire immediately or onblocked will.  So couldn't an app just
> assume it's blocked until it receives a onsuccess message?  The worst case
> is that the web app blinks up some message to the user to close other
> windows, but it seems like that could happen even with an onblocked event
> being added.  Am I missing something here?

I guess it isn't strictly needed, pages can always install a timeout
and cancel that timeout when the success event fires. But I think it
might be worth having still since it's generally hard to get people do
to proper error handling, and so it's extra important to make it easy
for people to do so.

/ Jonas

Small tweak to FileWriter's event sequences

[Eric Uhrhane]

The abort sequence in FileWriter looks like this:

"If readyState is DONE, throw a FileException with error code
INVALID_STATE_ERR and terminate this overall series of steps.
Set readyState to DONE.
Terminate any steps having to do with writing a file.
Dispatch a progress event called error. Set the error attribute to a
FileError object with the appropriate code (in this case, ABORT_ERR;
see error conditions).
Dispatch a progress event called abort
Dispatch a progress event called writeend
Stop dispatching any further progress events."

In this sequence, readyState gets set to DONE before any of the
progress events get sent out.  This leaves open a window of
opportunity in which one could start another write/truncate [e.g. in
onError] before the abort and writeend events get dispatched.  At that
point you'd get a writeend error that didn't refer to the write in
progress, which is at best nonintuitive.

I'm planning to move the setting of readyState to just before the
writeEnd event gets dispatched.
That way readyState==DONE always means it's safe to start another
operation, and an abort or writeend event is always  unambiguously
tied to a particular write.

Similarly, in the FileWriter's write and truncate sequences,
readyState gets set to DONE before the error and writeend progress
events are dispatched.  I'm going to make the same change there, for
the same reasons, and I'll alter the FileSaver's event sequence to
match.

Let me know if you see any problem with this.

Thanks,

 Eric

Re: [cors] Case-sensitive matching of origin URLs?

[Adam Barth]

On Fri, Sep 24, 2010 at 12:41 AM, Anne van Kesteren  wrote:
> On Thu, 23 Sep 2010 08:40:42 +0200, Vladimir Dzhuvinov
>  wrote:
>>
>> The CORS draft on the other hand requires case-sensitive matching of
>> origins:
>>
>> http://www.w3.org/TR/access-control/#resource-requests
>
> It requires case-sensitive matching of the serialization of origins. They
> are never parsed into origins to begin with.

Anne is correct.  CORS uses case-sensitive matching of the
serialization of origins.  It just so happens that whenever you
serialize an origin, you end up with something in lower case, but that
detail is too low-level for CORS to worry about.

Adam

[Bug 10734] New: Create LR Grammar

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10734

   Summary: Create LR Grammar
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: WebIDL
AssignedTo: c...@mcc.id.au
ReportedBy: ke...@kevlindev.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


This is a request to include an LR grammar of WebIDL in addition to the current
LL grammar. Having an LR grammar would make it easier to convert for parser
generators and is more conducive to building ASTs during the parse.

Thanks,
Kevin

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Small tweak to FileWriter's event sequences

[Kinuko Yasuda]

On Fri, Sep 24, 2010 at 1:15 PM, Eric Uhrhane  wrote:
> The abort sequence in FileWriter looks like this:
>
> "If readyState is DONE, throw a FileException with error code
> INVALID_STATE_ERR and terminate this overall series of steps.
> Set readyState to DONE.
> Terminate any steps having to do with writing a file.
> Dispatch a progress event called error. Set the error attribute to a
> FileError object with the appropriate code (in this case, ABORT_ERR;
> see error conditions).
> Dispatch a progress event called abort
> Dispatch a progress event called writeend
> Stop dispatching any further progress events."
>
> In this sequence, readyState gets set to DONE before any of the
> progress events get sent out.  This leaves open a window of
> opportunity in which one could start another write/truncate [e.g. in
> onError] before the abort and writeend events get dispatched.  At that
> point you'd get a writeend error that didn't refer to the write in
> progress, which is at best nonintuitive.
>
> I'm planning to move the setting of readyState to just before the
> writeEnd event gets dispatched.
> That way readyState==DONE always means it's safe to start another
> operation, and an abort or writeend event is always  unambiguously
> tied to a particular write.
>
> Similarly, in the FileWriter's write and truncate sequences,
> readyState gets set to DONE before the error and writeend progress
> events are dispatched.  I'm going to make the same change there, for
> the same reasons, and I'll alter the FileSaver's event sequence to
> match.
>
> Let me know if you see any problem with this.
>
> Thanks,
>
>     Eric
>
>

Re: [XHR2] ArrayBuffer integration

[Kenneth Russell]

On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren  wrote:
> On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell  wrote:
>>
>> Mozilla's experimental name is "mozResponseArrayBuffer", so perhaps to
>> avoid collisions the spec could call it responseArrayBuffer.
>
> While I do not think there would be collision (at least not in ECMAScript,
> which is what we are designing for) naming it responseArrayBuffer is fine
> with me. And also now done that way in the draft. Still need to get a saner
> reference to the ArrayBuffer specification than
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
> though. :-)
>
> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/

Thanks, this is great and very exciting. This motivates implementing
the proposed DataView interface (
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6
), which will make it easier to read multi-byte values with specified
endianness out of an ArrayBuffer. For WebKit I've filed
https://bugs.webkit.org/show_bug.cgi?id=46541 .

-Ken

> (You can also do send(ArrayBuffer) obviously. I personally think supporting
> this for both BlobBuilder and send() makes sense. That way Blob/File etc.
> work too.)
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [XHR2] ArrayBuffer integration

[Jian Li]

I plan to add ArrayBuffer support to BlobBuilder and FileReader. Chris, it
is good that you would pick up the work for XHR. We can talk about how we're
going to add ArrayBufferView to read ArrayBuffer.

Jian

On Fri, Sep 24, 2010 at 5:23 PM, Kenneth Russell  wrote:

> On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren 
> wrote:
> > On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell 
> wrote:
> >>
> >> Mozilla's experimental name is "mozResponseArrayBuffer", so perhaps to
> >> avoid collisions the spec could call it responseArrayBuffer.
> >
> > While I do not think there would be collision (at least not in
> ECMAScript,
> > which is what we are designing for) naming it responseArrayBuffer is fine
> > with me. And also now done that way in the draft. Still need to get a
> saner
> > reference to the ArrayBuffer specification than
> >
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
> > though. :-)
> >
> > http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
>
> Thanks, this is great and very exciting. This motivates implementing
> the proposed DataView interface (
>
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6
> ), which will make it easier to read multi-byte values with specified
> endianness out of an ArrayBuffer. For WebKit I've filed
> https://bugs.webkit.org/show_bug.cgi?id=46541 .
>
> -Ken
>
> > (You can also do send(ArrayBuffer) obviously. I personally think
> supporting
> > this for both BlobBuilder and send() makes sense. That way Blob/File etc.
> > work too.)
> >
> >
> > --
> > Anne van Kesteren
> > http://annevankesteren.nl/
> >
>
>

Re: [XHR2] ArrayBuffer integration

[Kenneth Russell]

On Fri, Sep 24, 2010 at 5:36 PM, Jian Li  wrote:
> I plan to add ArrayBuffer support to BlobBuilder and FileReader. Chris, it
> is good that you would pick up the work for XHR. We can talk about how we're
> going to add ArrayBufferView to read ArrayBuffer.

All of the Typed Array view types (Uint8Array, Float32Array, etc.)
except for Float64Array are already implemented in WebKit. The major
missing one for file and network I/O is DataView.

-Ken

> Jian
>
> On Fri, Sep 24, 2010 at 5:23 PM, Kenneth Russell  wrote:
>>
>> On Thu, Sep 23, 2010 at 2:42 AM, Anne van Kesteren 
>> wrote:
>> > On Wed, 08 Sep 2010 19:55:33 +0200, Kenneth Russell 
>> > wrote:
>> >>
>> >> Mozilla's experimental name is "mozResponseArrayBuffer", so perhaps to
>> >> avoid collisions the spec could call it responseArrayBuffer.
>> >
>> > While I do not think there would be collision (at least not in
>> > ECMAScript,
>> > which is what we are designing for) naming it responseArrayBuffer is
>> > fine
>> > with me. And also now done that way in the draft. Still need to get a
>> > saner
>> > reference to the ArrayBuffer specification than
>> >
>> > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
>> > though. :-)
>> >
>> > http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
>>
>> Thanks, this is great and very exciting. This motivates implementing
>> the proposed DataView interface (
>>
>> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6
>> ), which will make it easier to read multi-byte values with specified
>> endianness out of an ArrayBuffer. For WebKit I've filed
>> https://bugs.webkit.org/show_bug.cgi?id=46541 .
>>
>> -Ken
>>
>> > (You can also do send(ArrayBuffer) obviously. I personally think
>> > supporting
>> > this for both BlobBuilder and send() makes sense. That way Blob/File
>> > etc.
>> > work too.)
>> >
>> >
>> > --
>> > Anne van Kesteren
>> > http://annevankesteren.nl/
>> >
>>
>
>

Re: A URL API

[Devdatta Akhawe]

> If you really don't want to care what happened before, either do a
> clearParameter every time first, or define your own setParameter that
> just clears then appends.  Append/clear is a cleaner API design in
> general imo, precisely because you don't have to worry about colliding
> with previous activity by default.  A set/clear pair means that you
> have to explicitly check for existing data and handle it in a way that
> isn't completely trivial.

I am not saying remove append - I am saying that just also have set,
with the semantics that if you use set, its equivalent to clear;append

> Attempting to relegate same-name params to second-tier status isn't a
> good idea.  It's very useful for far more than the "old services that
> are also accessed via basic HTML forms" that you stated earlier.
>

I am not sure about that - I think a modern API design would be to
just send multiple values as an array (maybe CSV or TSV). Consider how
JSON values are encoded - do you have multiple values to denote
arrays? neither is this the case in XML (afaik). This semantic of
multiple yet different values for the same parameter is just
confusing, and as you said a mess for server side. I am less
optimistic than you are that it will be fixed.

cheers
devdtta


> ~TJ
>

Re: A URL API

[Tab Atkins Jr.]

On Wed, Sep 22, 2010 at 12:54 AM, Devdatta Akhawe  wrote:
>> 2) I've added two flavors of appendParameter.  The first flavor takes
>> a DOMString for a value and appends a single parameter.  The second
>> flavor takes an array of DOMStrings and appends one parameter for each
>> array.  This seemed better than using a variable number of arguments.
>
> -1
>
> I really want the setParameter method - appendParameter now requires
> the developer to know what someone might have done in the past with
> the URL object. this can be a cause of trouble as the web application
> might do something that the developer doesn't expect , so I
> specifically want the developer to opt-in to using appendParameters.

If you really don't want to care what happened before, either do a
clearParameter every time first, or define your own setParameter that
just clears then appends.  Append/clear is a cleaner API design in
general imo, precisely because you don't have to worry about colliding
with previous activity by default.  A set/clear pair means that you
have to explicitly check for existing data and handle it in a way that
isn't completely trivial.

> I know clearParameter is a method - but this is not the clear
> separation between the '2 APIs' that we talked about earlier in the
> thread.
>
> I remember reading about how some web application frameworks combine
> ?q=a&q=b to q=ab at the server side, whereas some will only consider
> q=a and some will only consider q=b. This is such a mess - the
> developer should have to specifically opt-in to this.

It's a mess for server-side languages/frameworks, yes.  Some of them
handle this incorrectly.  Most of the current crop of popular ones,
though, do things properly with one method that retrieves the last
value and one that retrieves all values (PHP is marginal in this
respect with its magic naming convention).

Attempting to relegate same-name params to second-tier status isn't a
good idea.  It's very useful for far more than the "old services that
are also accessed via basic HTML forms" that you stated earlier.

~TJ

[Bug 10420] Can you post sample of cross domain for web workers?

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10420


Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch,
   ||public-webapps@w3.org
  Component|HTML5 spec (editor: Ian |Web Workers (editor: Ian
   |Hickson)|Hickson)
 Resolution||NEEDSINFO
Product|HTML WG |WebAppsWG
  QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org




--- Comment #1 from Ian 'Hixie' Hickson   2010-09-25 04:47:06 ---
What kind of cross-domain? Do you mean creating a MessageChannel and passing
one MessagePort to a worker and another to a different origin?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting

[Robert O'Callahan]

On Mon, Sep 20, 2010 at 6:03 PM, Cameron McCormack  wrote:

> Art,
>
> Arthur Barstow:
> > * Web IDL - Cameron - will you attend this meeting?
>
> At this stage I won’t be attending.  I believe list discussion should be
> sufficient for progressing the spec at this point, and a scheduling
> conflict will make it difficult for me to attend regardless.


Yeah? I think as far as Mozilla is concerned, we could send you to this Nov
1-2 meeting if you want to go.

By the way, there is a Mozilla all-hands meeting scheduled December 13-17
(in Mountain View) that we'll definitely want you to to go.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]