Re: [whatwg] A thought: a href=... method=post
James Graham wrote: Kornel Lesinski wrote: On Wed, 11 May 2005 11:28:25 +0100, Mark Wubben [EMAIL PROTECTED] wrote: a href=/delete/$id/confirm action=/delete/$id method=postdelete/a That it doesn't look like data to send using POST method. I'm afraid that in most cases it will be used as: a href=# action=/delete/$id method=postdelete/a Wouldn't it work if a single URL in the the href attribute was used for both request types? i.e. simply a href=/delete/$id method=postdelete/a The serverside application would be expected to deal with GET requests on the URI in a sane way e.g. returning a confirmation page with a POSTable form on it +1 Server can figure out if the request has been made with GET or POST and it can behave correctly using to that information. During transition phase scripting can be used to POST the delete operation or scripting could be used to add something to the GET request (like ?jsconfirmdone=1). Details doesn't matter here as we're talking about workarounds that make the thing work without the confirmation page in UAs that don't support this new attribute method. Default fallback behavior would be to use confirmation page generated by the server. Broken server apps will be still broken and there's nothing we can write in the spec that forces every developer to create perfect applications. -- Mikko
Re: [whatwg] A thought: a href=... method=post
On May 13, 2005, at 06:28, Michael Gratton wrote: Most web applications I have seen (certainly nearly every one written in Java) do not differentiate between parameters provided by a GET or a POST; you can do either and the application will work in the same way. Of the various server-side frameworks available Java servlets are among the most cluefully designed when it comes to getting HTTP right. If a developer calls doPost from doGet, there is nothing the framework designer can do about it. I'm still -1 on changing the specs to accommodate people who have been ignoring RFC 2616. By the way, the main problem with the publicized case was that their non-idempotent GETs did not have query strings. Usually the people who don't respect the idempotency of GETs also have crufty URLs with query strings so that a robot can apply heuristics to avoid query strings. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] A thought: a href=... method=post
On Fri, 2005-05-13 at 16:47 +0300, Henri Sivonen wrote: Of the various server-side frameworks available Java servlets are among the most cluefully designed when it comes to getting HTTP right. If a developer calls doPost from doGet, there is nothing the framework designer can do about it. True. I am not bashing the Servlet API, I am just pointing out common practise. The Struts framework, for example, is a very popular Java framework built on the Servlet API but it calls the same processing method for both GETs and POSTs. Very poor form. Also, I think that because it uses same API to access parameters specified by both GET and POST requests it tends to encourage this sort of behaviour. But this is probably OT. I'm still -1 on changing the specs to accommodate people who have been ignoring RFC 2616. Ditto. Usually the people who don't respect the idempotency of GETs also have crufty URLs with query strings so that a robot can apply heuristics to avoid query strings. Which of course might punish sites (or users of sites) that have valid uses for query strings. /Mike. -- Michael Gratton, Software Architect. Quuxo Software http://web.quuxo.com/ signature.asc Description: This is a digitally signed message part
Re: [whatwg] A thought: a href=... method=post
Henri Sivonen wrote: On May 13, 2005, at 06:28, Michael Gratton wrote: Most web applications I have seen (certainly nearly every one written in Java) do not differentiate between parameters provided by a GET or a POST; you can do either and the application will work in the same way. Of the various server-side frameworks available Java servlets are among the most cluefully designed when it comes to getting HTTP right. If a developer calls doPost from doGet, there is nothing the framework designer can do about it. I'm still -1 on changing the specs to accommodate people who have been ignoring RFC 2616. That seems to be based on the belief that all things which look like links must correspond to idempotent actions. I don't think this is true and, in general, think that trying to couple the user interface to the underlying protocol is a bad idea. -- But if science you say still sounds too deep, Just do what Beaker does, just shrug and 'Meep!' -- Dr. Bunsen Honeydew Beaker of Muppet Labs
Re: [whatwg] A thought: a href=... method=post
On Fri, 13 May 2005 16:56:44 +0100, James Graham [EMAIL PROTECTED] wrote: That seems to be based on the belief that all things which look like links must correspond to idempotent actions. Yes, that is exactly the idea behind it. I don't think this is true and, in general, think that trying to couple the user interface to the underlying protocol is a bad idea. That is user interface which represents what protocol does. Links are not coupled with http GET method. You may link to any resource using any protocol, but following a link should not have side-effects - by design. Web applications usually don't have undo, so IMHO it should be clear that click on certain UI elements has side effects. Difference between radio buttons and checkboxes is quite clear by looks of them. There should be difference between links and buttons as well, because one _goes_ somewhere, and another _does_ something. In case with marking e-mail as read that would be element that _goes_ somewhere AND _does_ something, so I think that a might be suitable in this case. How about requiring non-idempotent links to have rel=nofollow? That might solve the google accelerator problem. -- regards, Kornel Lesinski
