Re: Progress Events normative text

On Mon, 15 Jun 2009 17:00:46 +0200, Charles McCathieNevile <chaals@opera.com> wrote:
> On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren <annevk@opera.com>  
> wrote:
>> That definitely makes sense, though please take into consideration that  
>> for cross-origin loads exposing the file size cannot be done until all  
>> HTTP headers have been received and the requested resource has opted in  
>> with CORS.
>
> OK. One of the things I intended to keep leaving to the "host" spec was  
> definining what the size actually refers to.

I'd think we would like this to consistently refer to the entity body for all usage of progress events as to not confuse people using the API. It seems odd to take great care in order and naming but not in consistent implementation of the event objects.


>> Since interaction with CORS will have to be defined by the  
>> specification defining the API (due to things such as source origin)  
>> the specifics of event dispatching will also need to be defined there  
>> and can probably not be done in a generic way. (Unless you make it  
>> integrate well with CORS semantics somehow I suppose, but that might  
>> just make matters more confusing.)
>
> Can you elaborate?

Exposing file size for cross-origin loads is a concern as I understand it. It makes it easier to do port scanning. So in order to prevent that resources loaded in a cross-origin fashion would have to opt in to sharing this information (much like they opt in to share the resource itself) and therefore they have to follow the model that CORS outlines.


>> Also, as currently phrased it seems to place limitations on  
>> specifications. E.g. if we want to introduce a timeout event in  
>> XMLHttpRequest for a specific operation the specification currently  
>> requires user agents to also dispatch a load/error/abort event in such  
>> scenarios
>
> Yes, that's the way I understand it.
>
>> which we do not want I think.
>
> Why not? (thinking out loud, it makes sense to me that the requirement  
> becomes a "should", enabling specs to define things in different ways  
> while providing some clear guidance to people who don't want to guess.  
> But if you have some clearer thoughts about use cases and requirements  
> that would be helpful...)

There's no reason for XHR2 to also dispatch one of load/error/abort if it already does both timeout and loadend. And I think you want to know the difference by the request being aborted due to a timeout versus a script or user initiated abort. Even SHOULD seems too strong for this in my opinion.


>>> Second, it should provide a reasonable default - if specifications are
>>> defining something significantly different then the defaults themselves
>>> should be changed to match that. But if they are not, then it is saving
>>> specifications from guessing what makes sense as a default behaviour...
>>
>> It seems to do a little more than saving specifications from guessing  
>> :-)
>
> Then what it says doesn't match what I intend it to say. Some more  
> detailed explanation would help me spot where the problems are.

"User agents must ensure that these events trigger event listeners attached on Element nodes for the relevant event and on the capture and target phases." does not work for XMLHttpRequest or XMLHttpRequestUpload. Neither is an Element node. Also, this requirement should be present in DOM Events and it would help I think if it was not restated here. (If you think it helps make it a non-normative note about DOM Events.)

"Specifications should use the events defined in this specification in preference to other events (e.g. in a different namespace, or with a different name) that offer the same functionality." is another example.

The section "Event firing order" duplicates text from e.g. XMLHttpRequest Level 2 which gives confusing and potentially contradictory requirements as I outlined above.


I think that just as in CORS it should be advice given to API specifications, not requirements.

Given that other specifications probably need to be fairly specific about when to dispatch certain progress events due to cross-origin loads etc. I still think it makes more sense to have no requirements in the specification regarding dispatching and have it be just an event name registry and interface description. On top of that you could have a single definition of what it means to dispatch a progress events:

  To *dispatch a progress event called x on y*, dispatch an
  event named x that implements the ProgressEvent interface
  on y with the members of the event object set as follows:

    namespace
      null
    bubbles
      false
    cancelable
      false
    lengthComputable
      true if the size of the resource is known. false
      otherwise.
    loaded
      The size of the entity body transferred so far.
    total
      The size of the entity body or zero if this is not
      known.


>> Also, section 3 still talks about the now renamed "start" event.  
>> Furthermore, it also suggests the total member includes the request and  
>> response metadata. I think we should restrict it to the entity body.
>
> Err, in normative text or in a random example? I intend to add more (and  
> more realistic) examples - if you have some text from e.g. XHR that I  
> could use, that would probably be very helpful.

It seems better to reference HTTP for entity body.


> In some cases it seems reasonable to restrict things to the entity body,  
> in other cases the response text is important - or both are... which is  
> why I plan to continue leaving that to the "host" spec.

Response text is the entity body, afaict.


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

Received on Wednesday, 17 June 2009 12:49:47 UTC