Since a URL query string is not a strict map with only one value for a
key, would the get/set operations allow for an array as well as an
atomic value?
On Fri, Oct 12, 2012 at 3:02 PM, Glenn Maynard wrote:
>
> The object paradigm is more natural for the common case:
>
> query.values["key"] = val
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
How about
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
> Sent: Monday, March 20, 2006 9:33 PM
> To: [EMAIL PROTECTED]
> Subject: [whatwg] A better name than for the element
> that shows ameasurement
>
>
> So one of the
> The use of 'class' for presentation is wrong anyway (and
> hopefully obsoleted in HTML 5). And yes, although it is named
> incorrectly, the attribute can take multiple, space-separated, values.
Not. For. Presentation. ???
Could you explain? I use that to map to CSS all the time. What am I doing
>
> Yet, I have to add that what we've suggested is (almost)
> useless. That's because the WA 1.0 specification already
> contains something that can solve what we wanted: profiles [1].
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/#profile
Can the 'class' attribute have multiple v
> Having rel/rev for a form element is logical. Hyperlink and
> form are inherently related in that both are used to specify
> protocol of communication. So, if hyperlink can have rel/rev,
> why not form?
It could, sure. But the original request was to define the purpose of the
URI in the action
There is some relevant discussion on the rest-discuss forum:
http://groups.yahoo.com/group/rest-discuss/message/5423
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dierken
> Sent: Sunday, November 06, 2005 12:42 PM
> To: &#x
> >
> >
> >
> >
> >
> > It would be cool to have a service that discovered these forms and
> > then provided a search of all the URIs that accepted
> > social-security-number, or zip-code.
>
> I must say you came with a really interesting idea. Yes, that
> would be good. I suppose you
> On Oct 18, 2005, at 06:14, S. Mike Dierken wrote:
>
> > Okay. Outbound messages are obviously not a problem. Accepting
> > unsolicited inbound messages isn't feasible (& the
> unsolicited part is
> > an invitation to spam). Having the client initiate
>
> > * Do you think that be able to use other HTTP methods, other than
> > GET, is important?
>
> In this case, not. The way I see it, web crawlers,
> extensions, user scripts, user agents and the like can use
> the URIs of any resource, based on the REL. For example,
> rel="author": thi
> > * Do you think being able to provide semantics between 2 resources
> > -- between 2 URI's -- is important?
>
> Yes, but not really for .
>
> Reason: generally speaking, an URI specified in the ACTION
> attribute of the is not a web page that shows general
> information, good for web c
> > For example, which (if any) of the following two FORMs is 'safe':
> >
> >> type='submit' value='go' />
> >
> >> type='submit' value='go' />
> >
>
> I don't see anything particularly unsafe about either of them, but I
> think I can see what you're getting at.
>
> Perhaps "without
> If the browser had an HTTP daemon built-in,
> would that work?
>
> No, since you can't guarentee that incoming connections will connect (e.g.
> because you are behind NAT with no port forwarding, a very common case).
If the client initiated the connection, then the roles were reversed, that
wo
> S. Mike Dierken wrote:
> >> 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 inte
I've put together a quick prototype to experiment with the event-source
design implications based on the WHAT-WG Web App spec here:
http://www.searchalert.net/dierken/eventsource/
This does not follow exactly the WebApp spec - rather, I'm making
suggestions about alternate approaches.
These are t
> To get around this whole issue we could just use a totally
> new HTTP method (other than "GET" or "POST"). Maybe "PING".
Cross-site POSTing is generally handled already. Self-site POSTing is the
problem of the site operator (e.g. a shared hosting environment like
Geocities, where the domain na
> 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
> Mike Dierken wrote:
>
> >How about not putting this notification URI in the anchors at all -
> >what about putting some metadata in the element that
> indicates
> >that /all/ links clicked should send a notification to the
> indicated service?
> >
> T
> > > >
> > > > 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 would posit that mos
>
> > 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 t
>
> > 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
32 matches
Mail list logo
