Re: [whatwg] URL: URLQuery
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"] = value; // get()
> console.log(query.values["key"]); // set()
> delete query.values["key"]; // delete()
> query.getAll("key"); // stays as-is
>
Re: [whatwg] JSONRequest
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 POST. So you would use POST rather than GET just in case an unsecured web application were contacted? In the situation that an unsecured web application were contacted, how often would a POST potentially modify data compared to a GET? (like http://www.sillyexample.org/folder?id=27&operation=delete - often no content body is required, and likely the content-type is unchecked anyway). A poorly written server-side application is doomed no matter what, so you might as well use a safe HTTP request method. > If the HTTP status code is not 200 OK, then the request fails. That doesn't sound good. What particular situations are bad? Re-direction makes servers easier to support and maintain. > Any cookies in the response header are discarded. That makes sense, no information leakage. > JSON messages are never cached. And you wouldn't use caching but you'd like to avoid a denial-of-service style attacks? > By switching to a policy of responding only to well-formatted JSONRequest, applications can be made more secure. Do you mean client-side applications (the browser) or the server side? > JSONRequest is designed to support duplex connections. Pretty standard stuff - I've done the same with XmlHttpRequest, and I think lots of folks have. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Douglas > Crockford > Sent: Wednesday, March 29, 2006 7:41 PM > To: [EMAIL PROTECTED] > Subject: [whatwg] JSONRequest > > > If application/json isn't acceptable (though I don't know > why it wouldn't be), > then try a hyphen instead: > application/json-request > > I like application/json-request. That is a good suggestion. > > The issue is to provide a way of identifying JSONRequest > transactions that cannot be confused with legacy applications. >
Re: [whatwg] A better name than for the element that shows ameasurement
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 HTML5 elements is : > >Relevancy: 70% > > Unfortunately, the study Google did on Web authors showed > that authors cannot spell the word "language", and I see no > reason to believe that they might spell "gauge" either. Also, > I've typoed the word "gauge" three times so far in this > e-mail, and in the thread where was first mentioned, > it was spelt in at least two different ways intentionally > (without even counting the typos in that thread). > > So. is out. What better element name can people think > of? I asked in some IRC channels, and looked at thesaurii, > and the some of the ideas I've so far dismissed are: > > -- looks odd when taken out of context > -- too close to " indicator" > -- too generic > -- too confusable with hit counters > -- too generic > -- too long > > is the best so far. I'm not sure it's better than . > > -- > Ian Hickson U+1047E > )\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ > _\ ;`._ ,. > Things that are impossible just take longer. > `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] rel/rev for ?
> 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 wrong?
Re: [whatwg] rel/rev for ?
> > 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 values? If not, then a new attribute would be needed, unless we overload the use of 'class' for presentation with the use of 'class' for semantic purposes.
Re: [whatwg] rel/rev for ?
> 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 attribute, not the relatioship between the action URI and the element, so rel/rev was overkill & possibly inappropriate. The meaning of a tag matching "html/body/[EMAIL PROTECTED]" is already documented - it defines the structure of a document acceptable by the resource identified by the action attribute. Defining the meaning of the document is probably more worthwhile, rather than the meaning of the resource that would accept that document. It would be cool to have the browser support POSTing some content type more sophisticated than www-url-encoded, like XML (no flames please). http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type I honestly have no idea if the WHAT-WG is working on that, or some other group, or what. > > As for the "tags" attribute discussion, you guys just > invented a "class" attribute. Well, that also was one suggestion, but 'class' is mostly for user interface rendering, rather than purely semantic meaning. But it may not be necessary or workable to have a 'purely semantic' attribute. Some web crawling system would likely be able to figure out the semantic equivalence if enough people used a small enough set of values for similar things.
Re: [whatwg] rel/rev for ?
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: 'ROBO Design' > Cc: 'WHAT WG List' > Subject: Re: [whatwg] rel/rev for ? > > > > > > > > > > > > > > > > > > > > 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 don't want the CLASS attribute for the > INPUTs to > > serve the purpose you've emphased. The REL attribute > wouldn't be good > > in this case. So, definitely a new one is needed. > > > > My suggestion would be to use the attribute named TAGS > (yes, I know it > > is inspired by del.icio.us and co., but ideas are always welcome). > > > > > > > > Separated by spaces, working much in the same way as REL. > The order of > > the tags does not matter and these could provide clues to > web crawlers > > and even browsers on the expected input. Microformats, in > the same way > > as with REL, could define various tags serving various > > purposes. Based on this, for example, a web browser could > > automatically provide a list of known ZIP codes in the US. > I was thinking too twentieth century - using multiple values > to 'tag' the semantic meaning of the input is better than a > single URI style 'unambigous' > value. As long as the syntax of the values within the 'tag' > allows for URI style 'unambigous' values, then both > approaches (URI-namespaces and > folksonomy) can be used. > > > > > This would be awesome, and would provide backwards compatibility, > > because everything else is still the same. > > Only newer browsers could greatly enhance (when users fill > > forms) the user experience. > > > > Yet, this is very different from the initial proposal Charles made. > Yeah, but I couldn't resist talking about what I've hoped > would come along all these years... >
Re: [whatwg] rel/rev for ?
> > > > > > > > > > > > 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 don't want the CLASS attribute > for the INPUTs to serve the purpose you've emphased. The REL > attribute wouldn't be good in this case. So, definitely a new > one is needed. > > My suggestion would be to use the attribute named TAGS (yes, > I know it is inspired by del.icio.us and co., but ideas are > always welcome). > > > > Separated by spaces, working much in the same way as REL. The > order of the tags does not matter and these could provide > clues to web crawlers and even browsers on the expected > input. Microformats, in the same way as with REL, could > define various tags serving various purposes. Based > on this, for example, a web browser could automatically > provide a list of known ZIP codes in the US. I was thinking too twentieth century - using multiple values to 'tag' the semantic meaning of the input is better than a single URI style 'unambigous' value. As long as the syntax of the values within the 'tag' allows for URI style 'unambigous' values, then both approaches (URI-namespaces and folksonomy) can be used. > > This would be awesome, and would provide backwards > compatibility, because everything else is still the same. > Only newer browsers could greatly enhance (when users fill > forms) the user experience. > > Yet, this is very different from the initial proposal Charles made. Yeah, but I couldn't resist talking about what I've hoped would come along all these years...
Re: [whatwg] web-apps - TCPConnection
> 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 the connection & > > then receiving/ responding to inbound requests is what it > sounds like > > you would need. > > If the browser had an HTTP daemon built-in, would that work? > > A HTTP daemon in the browser is not strictly required. > > Rumor (which I have not verified) has it that there are > successful IP over HTTP implementations for the purpose of > circumventing strict corporate firewalls. An HTTP client > behind the firewall issues requests to an accomplice HTTP > server outside the firewall which routes the IP packets to > and from the Internet. Outbound packets are POSTed to the > server. The server sends inbound packets in the response > stream of the most recent POST. The responses are closed on > the server only upon seeing the next POST request. > Sure, tunneling is always technically possible. But I'm trying to avoid 'circumventing' anything and am trying to use exisitng standards and technology - it's better that writing our own bugs and tends not to get shut down by administrators.
Re: [whatwg] rel/rev for ?
> > > * 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": this *should* give an URI to the author of the > web page, but how would this work with a ? Would you > require it to use POST or another method? Forms are more > complex than simple links, they require user interaction > (fill the fields and most likely a JavaScript on the page > that validates the values). > > Also, forms are not for "general availability", in the sense > of ... web crawlers should *not* try to submit them (that's > what the bad spam bots do when trying to post spam comments). I actually would find it interesting and useful for a the inputs of a form to have a 'class' attribute that indicates the meaning of the parameter - and let a web crawler find all the forms that use a certain class of input parameters. For example: 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.
Re: [whatwg] rel/rev for ?
> > * 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 crawlers nor the like. I wouldn't > like bots going crazy in my s :). The 'rel' attribute establishes a relationship between the identified resource and the current document. It looks like the suggested 'rel' attribute identifies the meaning of the identified resource, independent of the current document. A rel value of "this document is a description of the service at 'foo'" would be more appropriate. I do think an attribute that describes the 'type' of service that the action attribute references would be good. Doing a 'HEAD' request on the URI in the action attribute could provide the data that indicates the 'purpose' of that resource. Not that this is the best approach, but using 'rel' might be overkill. What you want is a resource description framework and some documented means of getting metadata about a resource (service).
Re: [whatwg]
> > 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 side-effects" or "idempotent" might be better > descriptions than "safe"? The above two forms both look like they're > doing exactly what they were intended to do, and therefore don't seem > "unsafe" at all... I'm pretty sure I'm doing a very poor job communicating what I'm thinking... So thanks for sticking with this. Each of the HTTP methods GET, PUT and DELETE are idempotent (repeating them results in the same state). Only GET is safe (no data is intended by the client to be modified).
Re: [whatwg] web-apps - TCPConnection
> 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 would mirror the TCPConnection approach. > > Also, requiring that UAs implement HTTP servers, as opposed > to just implementing the simple TCPConnection protocol > described at the moment, seems like a significantly more > expensive way of solving this problem. A full (i.e. complex) server wouldn't be necessary, just the protocol parsing. Implementing the protocol for simple use is straightforward, and bringing in Apache as a library would be one approach. > > > > > Another example would be something like an IM or chat client. All > > > the current implementations of that are huge hacks that would be > > > much simpler to implement if they could just open a TCP connection > > > and send free-form data back and forth. > > > > I've implemented IM and chat applications with just HTTP, HTML and > > Javascript. In a browser. Without plugins. > > Yes, lots of people have. It would be a lot simpler with a > bidirectional asynchronous text-based messaging protocol, though. >From my perspective, it would be a lot simpler to re-use a working protocol (HTTP) rather than start over & re-learn all the mistakes of the past. > > > > The DOM Event portion of the specification is very similar & more than > > sufficient for chat and IM. > > That's one way of receiving messages, but it isn't as good for sending > them. Using HTTP to send them requires some acrobatics on the server side. > Using TCPConnection would just mean one process server side. How is using HTTP going to require acrobatics on the server side? I must be misunderstanding what you are thinking, because there are dozens of implementation of HTTP servers. > > > > It's unfortunate that port 80 would be needed to 'tunnel out', but I > > realize that's the situation most people are in. But I really recommend > > that a port 80 outbound tunnel use the protocol assigned to that port - > > via the HTTP Upgrade header. > > That would require that the Web author implement HTTP on his side (or at > least a simple version of an HTTP server) which seems like undue work. My opinion is that 'implement HTTP' means 'reading and parse a text stream' - not undue work, even for a 'Web author'. > What would the advantage be? We're not connecting to an HTTP server. > Upgrade makes sense if you are upgrading from HTTP to something, but here > we're not expecting HTTP to ever be used over the connection. The point is that since you want to initiate a connection on port 80, then you should use the protocol assigned to that port. It has specified mechanisms to upgrade to a proprietary protocol - it doesn't cost a whole heck of a lot & you wind up being standards compliant. > > > > > We don't want to require that authors implement an entire HTTP server > > > just to be able to switch to a proprietary protocol. > > > > Nobody has suggested requiring an entire server. Two messages is all it > > takes. Not only does HTTP scale up well, it scales down too. > > No, because you have to implement correct handling of everything _other_ > than Upgrade: as well, even if it is to return "Not Supported" each time. Good point. > You have to parse headers, etc. Nobody is going to actually bother to > correctly implement that, and if they don't, what's the point in > pretending that they do? It would just make matters worse, with obscure > per-server/client pair bugs for browsers to work around. Browsers don't need to work around a broken server, regardless of which spec the server author didn't follow.
Re: [whatwg]
> 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 intent is to modify the data > > identified by the resource - data modification is tagged as > being 'unsafe'. > > I think your confusing this with the fact that using GET > requests for data modification is unsafe, and seem to be > saying that POST is unsafe when used as intended!? > Yes - I'm trying to use the terms 'safe' and 'unsafe' to mean 'read-only' and 'not read-only', respectively. That's the usage of 'safe' and 'unsafe' with respect to HTTP that I'm familiar with. For example, which (if any) of the following two FORMs is 'safe':
[whatwg] event-source prototype and questions
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 the points I'd like to start a discussion about:
* What markup is used within a page?
* How are incoming messages routed to script handlers?
* What javascript is used to receive messages?
* What event stream format is used?
* How are resources/URIs used?
This experiment/prototype is a simple bit of javascript that fetches a set
of messages and dispatches them to handlers within the page.
I'd be very happy if some folks could take a look at the comments and
questions on that page as well as the source of the prototype.
Also - one thing I couldn't figure out how to do with the javascript protype
was to dispatch to a javascript function and have that function access an
object by name without having to declare that object as a parameter to that
method.
For example:
I'd like to be able to write this:
function handleStocks()
{
alert(msg.content);
}
http://example.org/stock-stream"; onMessage="handleStocks()"
/>
But instead I had to write this:
function handleStocks(msg)
{
alert(msg.content);
}
http://example.org/stock-stream";
onMessage="handleStocks(msg)" />
I tried using closures in several different ways and couldn't get it to
work. Any help would be appreciated - not necessarily to make the prototype
better, but just for my own education.
Re: [whatwg]
> 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 name is shared among many questionable authors.) The intent of tracking a user's attention (their click activity) genuinely deserves POST. I have retracted my original concerns.
Re: [whatwg]
> 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 that operate on any number of sites and understand how to avoid 'unsafe' operations. In the case of Flickr, if I used a pre-fetching tool or client side spider/indexer, those images would be toast without my knowing about it. Traversing a URI should be 'safe' - this opens up new application possibilities. > > A website like Flickr should require authentication of the > user before allowing photos to be deleted. Yes, and they shouldn't use GET to modify data.
Re: [whatwg]
> 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'. This is a narrow definition of 'unsafe' and is only in relation to GET, HEAD and OPTIONS where the user is not liable for changes/damages that may happen due to those requests. They are however liable for changes that are a result of POST (or PUT or DELETE). In this use case of notifying trackers, I earlier called it 'unsafe' because I mixed up concerns of privacy and hijacking pages with this use. That was incorrect. > > There's nothing wrong with POST being used for this purpose > IMHO, but I'd be very interested to hear arguments to the contrary. I now agree - state is being transferred from the client to the server.
Re: [whatwg]
> > 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 isn't the best method - the state being transferred is the activity happening within the user-agent, so a POST makes sense.
Re: [whatwg]
> 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? > > > That idea has several obvious flaws, the two most important > being that you wouldn't be able to have different "pings" for > different links (ads from different providers, for example), > and it would force all links on a page to "ping", which is > very rarely desired. > Yes - you are right of course. I wasn't thinking clearly of the actual use-case, just over-generalizing.
Re: [whatwg]
> > > > > > > > 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 most users hover over a lot of links > before they decide which one is most enticing to them. I am > also interested to hear of a use case for this feature? Just thinking out loud, trying to figure out the general pattern of what this really means, in order to determine whether something important is being missed or misused.
Re: [whatwg]
> > > 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 > 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 Here 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? http://myattention.org/dierken"; rev="attention-tracker" />
Re: [whatwg]
> > > 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 Here > > This would be way too much. On copy/hover/click? You'd want this? > I wouldn't. Companies would definitely want this. > > You anticipated something that will happen. Not now, not in this > specification. It's too much at once. Everything must be > taken slowly, > step by step. First step is ping=. > True - but if you use a name that is descriptive, the future extensions would be easier to migrate into.
Re: [whatwg]
> > > > 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 would > cause a *lot* of network traffic. Probably more than most > server admins would like. Well, the client would only need to send one. Transferring state only needs to happen once - I'm assuming a UI event isn't what the website operator is interested in.
Re: [whatwg]
> 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 own photos, or photos of those whom > they had stolen the authentication details for. This is not exactly a > new problem. This is off-topic, but the problem is a GET request that results in deleted data. I think that you agree that is the problem here (and it's unrelated to the proposal for gathering click history).
Re: [whatwg]
> 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 attention is being spent (the click event I mean), should you also define the other set of events of interest as well? Wicked Cool Stuff Here What is the request method for these notifications (the wording "the URIs would be followed" imply retrieval)? If POST, what is the content body? If GET, what is the URI (generated from the href via a pattern, or static from the downloaded html)? Should the Referer request header also be sent (except for documents retrieved via secure protocols)? Should the notification event occur before, during or after the retrieval of the href="..." resource? Should the notification event occur for only succesful retrievals? Or should the notification contain the response status of incomplete retrievals of the href="..." resource? Should the notification URIs be restricted to the same host/domain as a) the source document b) the href="..." resource or c) unlimited?
Re: [whatwg]
> > > > 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 cost someone money. Hence > POST. (This is another advantage of ping over redirects, come > to think of it.) Since it isn't costing the /user/ any money, aren't those server side-effects immaterial? GET means that you can do it again, and you don't affect anything - two separate concepts. PUT and DELETE means that you can do it again (the final result is the same), and you may affect something. POST means you can't do it again, and you may affect something. It still seems dangerous, but I can't come up with a valid scenario. Party on.
Re: [whatwg]
> > 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 server is being retrieved, but it still bugs me. Maybe I'm just reacting to the (lack of) privacy issue. > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2 Section 9.1.1 - "...allow the user to be aware of any actions they might take which may have an unexpected significance..." "...This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested." Will the user-agent represent these links in a special way, so the user is made aware of the fact that a possibly unsafe action is being requested? > > I would say it's OK to send a POST as a side effect because > it's going to an URL where the developer expects a POST. But that's not what the user clicking the link expects. > If you can come up with a reason why it's not safe, I'd like to hear it. My initial reaction was to be concerned about a malicious link that triggered a POST for a resource that becomes modified or deleted - like href="http://www.flickr.com/photos/dierken/?delete=39177102&magic_cookie=528 479cac210fc6z837c0ac708334fe6" (Those freaking blockheads at Flickr just deleted my picture when I pasted that URI into the browser window. Losers - when will they realize that an anchor is not a UI widget. Thank goodness that I don't have a pre-fetch utility running or I'd lose all my vacation photos.) But of course anybody that can cause that extra attribute to appear on an anchor, likely has enough control to do some damage anyway.
Re: [whatwg]
> > 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.
Re: [whatwg]
> > 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 POST some data, but in this case, it would be a GET request - that may get confusing. Perhaps 'also-get' or 'snoop-href' something like that. Ideally, the data within the tags would be able to have more than one anchor and each would have different roles, but I don't think HTML supports that (except for the elements in the section since they apply to the containing document). For example: this uses nested anchors - which are illegal (nested anchors are illegal I know... http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2.2) So the pragmatic alternative is exactly as you suggest - a new attribute. > Thoughts? Is it evil? Yes, but even the anti-christ is just another customer.
Re: [whatwg] web-apps - TCPConnection
> 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. 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 the connection & then receiving/responding to inbound requests is what it sounds like you would need. If the browser had an HTTP daemon built-in, would that work? > Another example > would be something like an IM or chat client. All the current > implementations of that are huge hacks that would be much > simpler to implement if they could just open a TCP connection > and send free-form data back and forth. I've implemented IM and chat applications with just HTTP, HTML and Javascript. In a browser. Without plugins. The DOM Event portion of the specification is very similar & more than sufficient for chat and IM. > > > > It seems bizarre to introduce this section into a Web browsing > > environment where HTTP is available to define most of the interactions > > described in this section. > > HTTP is a stateless synchronous protocol for resource > management. The TCPConnection interface is a stateful > asynchronous protocol for bidirectional realtime > communication. They are very different. > > > > I realize this is just a draft, but there are some odd > descriptions - > > for example, the TCPConnection must use port 80 (the port > that defines > > HTTP), but later the communication requirements define a completely > > different and new protocol on that port: > > It's not intended to use port 80 only; where does it say > that? That's an error. It is intended to be usable on ports > 80, 443, and anything greater than 1024. (80 and 443 to > attempt to tunnel out of psychotic firewalls, and anything > greater than 1024 so that you can't talk to things like SMTP > or FTP servers, something that could allow all kinds of > security problems. > The handshake also attempts to reduce the risk of security issues.) I misread the specification - I thought it restricted usage to just port 80/etc. It's unfortunate that port 80 would be needed to 'tunnel out', but I realize that's the situation most people are in. But I really recommend that a port 80 outbound tunnel use the protocol assigned to that port - via the HTTP Upgrade header. > > > > "Once a TCP/IP connection to the remote host is > established, the user > > agent must transmit the following sequence of bytes, > represented here > > in hexadecimal form: 0x48 0x65 0x6C 0x6C 0x6F 0x0A This > represents the > > string "Hello" followed by a newline, encoded in UTF-8. " > > > > This whole section seems somewhat unnecessary. If you are trying to > > securely establish a connection & then switch to a > private/proprieatry > > protocol, you can use the Upgrade header to transition beyond HTTP > > once the connection is established: > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42 > > We don't want to require that authors implement an entire > HTTP server just to be able to switch to a proprietary > protocol. Nobody has suggested requiring an entire server. Two messages is all it takes. Not only does HTTP scale up well, it scales down too.
[whatwg] web-apps - TCPConnection
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 is available to define most of the interactions described in this section. I realize this is just a draft, but there are some odd descriptions - for example, the TCPConnection must use port 80 (the port that defines HTTP), but later the communication requirements define a completely different and new protocol on that port: "If the target host is not a valid host name, or if the port argument is not either equal to 80, 443, or greater than 1024 and less then 65537, then the UA must raise a security exception." "Once a TCP/IP connection to the remote host is established, the user agent must transmit the following sequence of bytes, represented here in hexadecimal form: 0x48 0x65 0x6C 0x6C 0x6F 0x0A This represents the string "Hello" followed by a newline, encoded in UTF-8. " This whole section seems somewhat unnecessary. If you are trying to securely establish a connection & then switch to a private/proprieatry protocol, you can use the Upgrade header to transition beyond HTTP once the connection is established: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42 "The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by the server, possibly according to the nature of the method and/or resource being requested)."
