[whatwg] Radio UserLand: Mail from Ian Hickson

[Maciej Stachowiak]

On May 18, 2007, at 4:19 PM, Ian Hickson wrote:

> On Fri, 22 Apr 2005, Brad Neuberg wrote:
>>
>> Here's a possible API for GET and POST semantics without  
>> XmlHttpRequest:
>>
>> window.location.href = base URL + URL parameters already appended
>> window.location.method = GET or POST, nothing else supported
>>
>> If the method is a POST method, the internal code simply pulls all  
>> the
>> parameters off of window.location.href and builds up a POST request
>> using them.  Should it URL encode each query parameter and key  
>> first, or
>> assume that they are already URL-encoded?
>
> Would this just be to do a scripted navigation to a POST page?
>
> A .method property on 'location' is an interesting idea, but it would
> probably end up confusing (what if you set it and another script  
> does a
> .href="" thinking it will do a GET?).

I think parsing the query part of a URL to resubmit as an http post  
body is also in general inappropriate, since one may validly POST data  
to a URL with a query part. Granted this is an edge case but there are  
certainly cleaner ways to supply a body.

> window.location.post() is probably the best plan if we want to do  
> this, I
> think. The question is, what exactly is the use case? Do we want to be
> doing POSTs like this without the user knowing, and with JS required?

Even without use of JS, you could style a <button type="submit"> for a  
form of otherwise hidden fields to look like a link, to make something  
that posts but looks like a normal link. To submit programatically,  
you can dynamically create a form. For cases where that is not a good  
way to build up the post body, an explicit location.post() method (or  
more generally location.load that takes URI, method, body and headers)  
would indeed be better than using multiple properties of the location  
object.

Regards,
Maciej