Wow. Pretty, uh, interesting.
Why not just have XmlHttpRequest configurable to not share cookies, not
share auth, not accept anything but xml, etc.?
> Does this allow improperly secured applications to be accessed?
> Application that are looking GET cannot be accessed because JSONRequest
only uses
> It's already possible to POST to arbitrary URLs just by
> putting any old URL in the /action/ attribute of a and
> submitting it with JS or fooling the user into clicking the
> submit button.
True. One interesting aspect of keeping the number of methods small is that
utilities can be built th
> I'm not sure where this idea has come from that sending POSTs
> is inherently unsafe (which, by the way, no-one has offered a
> good explanation for yet).
POST requests are unsafe because the intent is to modify the data identified
by the resource - data modification is tagged as being 'unsafe'
>
> Yeah, that's my thinking too. Perhaps we could use a totally
> new HTTP method for this (instead of "GET", "POST", or any of
> the other existing ones out there). Maybe "PING"
Hmm. That's one way for me to be happy that it's a POST - suggest a new HTTP
method.
I've finally agreed that GET
>
> > Since this is effectively capturing where the user's attention is being
> > spent (the click event I mean), should you also define the other set of
> > events of interest as well?
> > > on-hover-notify="myattention.org/dierken"
> > on-copy-notify="myattention.org/dierken">Wicked Cool Stuff
> >
> > Since this is effectively capturing where the user's attention is
> > being spent (the click event I mean), should you also define the other
> > set of events of interest as well?
> > > on-hover-notify="myattention.org/dierken"
>
> I realise this is hypothetical, but on-hover-notify w
>
href="http://www.flickr.com/photos/dierken/?delete=39177102&magic_cookie=528
479cac210fc6z837c0ac708334fe6"
>
> I would certainly hope that Flickr requires authentication
> before an URL
> like that had any effect, in which case the developer of the website
> would only be able to delete their
> Bearing the above in mind, I've added a section to the
> element that describes a ping="" attribute. The URIs given in
> this attribute would be followed when the user clicks the
> link, thus getting around the problems listed above.
Since this is effectively capturing where the user's atte
> >
> > Oh, that really shouldn't be done via POST. Clicking a link should be
> > safe and sending a POST as a side-effect is not safe.
>
> GET means that you can do it again without affecting
> anything. In the case of tracking, you can't -- the very act
> of contacting that tracking URI can c
>
> It definitely should be a POST, because the action performed by it is not
idempotent. See [1].
I agree is seems logical to use POST - the actual URI being visited by the
user likely would be in the content body (although a request header similar
to Referer could be used) and no state from the
> > Or is it just "hitting" -- making an hidden HTTP GET request of each
> > token in the "ping" attibute?
>
> Right. Hidden HTTP POST request, as it happens, but yes.
Oh, that really shouldn't be done via POST. Clicking a link should be safe
and sending a POST as a side-effect is not safe.
>
> Bearing the above in mind, I've added a section to the
> element that describes a ping="" attribute. The URIs given in
> this attribute would be followed when the user clicks the
> link, thus getting around the problems listed above.
The term 'ping' in terms of RSS/blogs often means to POS
> On Sun, 16 Oct 2005, S. Mike Dierken wrote:
> >
> > http://whatwg.org/specs/web-apps/current-work/#network
> >
> > My only question is - why?
>
> Imagine trying to play a game like Quake implemented in a Web
> page. You need bidirectional communication.
O
Title: web-apps - TCPConnection
I just noticed this section of the web-apps 1.0 specification regarding TCP connections.
http://whatwg.org/specs/web-apps/current-work/#network
My only question is - why?
It seems bizarre to introduce this section into a Web browsing environment where HTTP
14 matches
Mail list logo
