Re: A URL API

[Adam Barth]

Ok.  I'm sold on having an API for constructing query parameters.
Thoughts on what it should look like?  Here's what jQuery does:

http://api.jquery.com/jQuery.get/

Essentially, you supply a JSON object containing the parameters.  They
also have some magical syntax for specifying multiple instances of the
same parameter name.  I like the easy of supplying a JSON object, but
I'm not in love with the magical syntax.  An alternative is to use two
APIs, like we current have for reading the parameter values.

Adam


On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe  wrote:
> or any webservice that likes to have lots of query parameters - Google
> Search for example.
>
> In general, why would you not want a robust way to make complicated
> queries - those who are making simple queries and prefer simple one
> liners can continue using it.
>
>
> On 20 September 2010 23:42, Darin Fisher  wrote:
>> On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith 
>> wrote:
>>>
>>> On 9/20/10, Julian Reschke  wrote:
>>> > On 20.09.2010 18:56, Garrett Smith wrote:
>>> [...]
>>> >> Requests that don't have lot of parameters are often simple one-liners:
>>> >>
>>> >> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
>>> >
>>> > That's exactly the kind of code that will fail once "pid" and "zip"
>>> > contain things you don't expecz.
>>> >
>>> >> What XHRs have complicated URL with a lot of query parameters?
>>> >
>>> > What XHRs?
>>> >
>>> IOW, what are the cases where an XHR instance wants to use a lot o query
>>> params?
>>>
>>
>> Probably when speaking to a HTTP server designed to take input from an HTML
>> form.
>> -Darin
>>
>

Re: A URL API

[Devdatta Akhawe]

or any webservice that likes to have lots of query parameters - Google
Search for example.

In general, why would you not want a robust way to make complicated
queries - those who are making simple queries and prefer simple one
liners can continue using it.


On 20 September 2010 23:42, Darin Fisher  wrote:
> On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith 
> wrote:
>>
>> On 9/20/10, Julian Reschke  wrote:
>> > On 20.09.2010 18:56, Garrett Smith wrote:
>> [...]
>> >> Requests that don't have lot of parameters are often simple one-liners:
>> >>
>> >> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
>> >
>> > That's exactly the kind of code that will fail once "pid" and "zip"
>> > contain things you don't expecz.
>> >
>> >> What XHRs have complicated URL with a lot of query parameters?
>> >
>> > What XHRs?
>> >
>> IOW, what are the cases where an XHR instance wants to use a lot o query
>> params?
>>
>
> Probably when speaking to a HTTP server designed to take input from an HTML
> form.
> -Darin
>

Re: A URL API

[Darin Fisher]

On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith wrote:

> On 9/20/10, Julian Reschke  wrote:
> > On 20.09.2010 18:56, Garrett Smith wrote:
> [...]
> >> Requests that don't have lot of parameters are often simple one-liners:
> >>
> >> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
> >
> > That's exactly the kind of code that will fail once "pid" and "zip"
> > contain things you don't expecz.
> >
> >> What XHRs have complicated URL with a lot of query parameters?
> >
> > What XHRs?
> >
> IOW, what are the cases where an XHR instance wants to use a lot o query
> params?
>
>
Probably when speaking to a HTTP server designed to take input from an HTML
form.

-Darin

[CORS] HTTP error codes in preflight response

[Jonas Sicking]

Hi All,

CORS was recently clarified to say that error responses, such as
4xx/5xx responses, should not abort the various algorithms but instead
such a response should be forwarded to, for example, the
XMLHttpRequest implementation.

However it seems somewhat strange to me to do this with responses to
the preflight OPTIONS request. If a OPTIONS request results in a 404,
then it seems to me that the request can not be considered successful,
and that access to place the "real" request should not be granted.
Otherwise we are essentially ignoring the status code and not exposing
it anywhere, which seems strange.

/ Jonas

Re: [IndexedDB] IDBCursor.update for cursors returned from IDBIndex.openCursor

[Jonas Sicking]

On Fri, Sep 17, 2010 at 3:14 PM, Jonas Sicking  wrote:
>> Given that the key-returning versions of these functions are just
>> optimizations, at the very least, we should change the names though:
>> get->getKey (or maybe getPrimaryKey?)
>> openCursor->openKeyCursor (or maybe openPrimaryKeyCursor?)
>> getObject->get
>> openObjectCursor->openCursor
>
> I can't say that I feel strongly on the naming issue. Will ask around
> here to see how people feel.

This sounds like a workable solution. And also make IDBCursor.update
and IDBCursor.delete throw an exception if called on a key-cursor.

/ Jonas

Re: A URL API

[Garrett Smith]

On 9/20/10, Julian Reschke  wrote:
> On 20.09.2010 18:56, Garrett Smith wrote:
[...]
>> Requests that don't have lot of parameters are often simple one-liners:
>>
>> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
>
> That's exactly the kind of code that will fail once "pid" and "zip"
> contain things you don't expecz.
>
>> What XHRs have complicated URL with a lot of query parameters?
>
> What XHRs?
>
IOW, what are the cases where an XHR instance wants to use a lot o query params?

Garrett

Re: A URL API

[Julian Reschke]

On 20.09.2010 18:56, Garrett Smith wrote:

No idea; I wouldn't expect it to work, even if some browser actually
supported something other than GET|POST. I've always used "get" or
"post" and that's what's stated in HTML4.



Might a large-ish form request, a standard form submission be a better
alternative to XHR?


Depends on the application.

One reason to use XHR is that you want to interact with an HTTP service 
that hasn't been written for a web browser.


Whether services like this require complicated URI construction is a 
separate issue. Some do. And I'm pretty sure that people *will* get URI 
construction wrong due to delimiters, non-ASCII characters and so on.



Requests that don't have lot of parameters are often simple one-liners:

url = "/getShipping/?zip=" + zip + "&pid=" + pid;


That's exactly the kind of code that will fail once "pid" and "zip" 
contain things you don't expecz.



What XHRs have complicated URL with a lot of query parameters?


What XHRs?

Best regards, Julian

Re: A URL API

[Garrett Smith]

On 9/20/10, Julian Reschke  wrote:
> On 20.09.2010 09:22, Garrett Smith wrote:
>> ...
>> I see setParameterValues there. Useful to build URLs for XHR. But OTOH
>> -- Ajax that is using a lot of parameters, might be better using a
>> form. Usually Ajax requests are simple requests -- not a large form
>> submission. Sorry just have to be devils advocate on the necessity of
>> the thing.
>> ...
>
> How do you use a form to build a request other than GET/POST?
>
>
No idea; I wouldn't expect it to work, even if some browser actually
supported something other than GET|POST. I've always used "get" or
"post" and that's what's stated in HTML4.



Might a large-ish form request, a standard form submission be a better
alternative to XHR?

Requests that don't have lot of parameters are often simple one-liners:

url = "/getShipping/?zip=" + zip + "&pid=" + pid;

What XHRs have complicated URL with a lot of query parameters?

Garrett

Re: A URL API

[Anne van Kesteren]

On Mon, 20 Sep 2010 10:01:01 +0200, Adam Barth  wrote:

Using the method attribute of the form element.


It will not get you further than GET/POST; and PUT/DELETE with same-origin  
limitation. It also does not allow for custom headers, custom entity body,  
etc.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: A URL API

[Julian Reschke]

On 20.09.2010 10:01, Adam Barth wrote:

On Mon, Sep 20, 2010 at 12:34 AM, Julian Reschke  wrote:

On 20.09.2010 09:22, Garrett Smith wrote:


...
I see setParameterValues there. Useful to build URLs for XHR. But OTOH
-- Ajax that is using a lot of parameters, might be better using a
form. Usually Ajax requests are simple requests -- not a large form
submission. Sorry just have to be devils advocate on the necessity of
the thing.
...


How do you use a form to build a request other than GET/POST?


Using the method attribute of the form element.


OK. So I set the method attribute to "FOOBAR", and then how do I proceed 
generating an HTTP request from there?


Best regards, Julian

Re: A URL API

[Adam Barth]

On Mon, Sep 20, 2010 at 12:34 AM, Julian Reschke  wrote:
> On 20.09.2010 09:22, Garrett Smith wrote:
>>
>> ...
>> I see setParameterValues there. Useful to build URLs for XHR. But OTOH
>> -- Ajax that is using a lot of parameters, might be better using a
>> form. Usually Ajax requests are simple requests -- not a large form
>> submission. Sorry just have to be devils advocate on the necessity of
>> the thing.
>> ...
>
> How do you use a form to build a request other than GET/POST?

Using the method attribute of the form element.

Adam

Re: A URL API

[Julian Reschke]

On 20.09.2010 09:22, Garrett Smith wrote:

...
I see setParameterValues there. Useful to build URLs for XHR. But OTOH
-- Ajax that is using a lot of parameters, might be better using a
form. Usually Ajax requests are simple requests -- not a large form
submission. Sorry just have to be devils advocate on the necessity of
the thing.
...


How do you use a form to build a request other than GET/POST?

Re: A URL API

[Garrett Smith]

On 9/19/10, Julian Reschke  wrote:
> On 20.09.2010 08:27, Adam Barth wrote:
>> On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe
>> wrote:

> Keep in mind that the original use case was making life easier for
> people using XmlHttpRequest, and that covers many more use cases than forms.
>
Yep, I just took a quick glance at the Closure docs Ojan linked up
too. Docs look good; haven't looked at the code.

I see setParameterValues there. Useful to build URLs for XHR. But OTOH
-- Ajax that is using a lot of parameters, might be better using a
form. Usually Ajax requests are simple requests -- not a large form
submission. Sorry just have to be devils advocate on the necessity of
the thing.

BTW it's XMLHttpRequest -- I can't help but memorize these things
after typing them a few hundred times.

Regards.