From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 3CDEA7EE25 for ; Tue, 29 Oct 2013 13:14:22 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of of12343@my.bristol.ac.uk) identity=pra; client-ip=209.85.212.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="of12343@my.bristol.ac.uk"; x-sender="of12343@my.bristol.ac.uk"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of of12343@my.bristol.ac.uk) identity=mailfrom; client-ip=209.85.212.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="of12343@my.bristol.ac.uk"; x-sender="of12343@my.bristol.ac.uk"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f173.google.com) identity=helo; client-ip=209.85.212.173; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="of12343@my.bristol.ac.uk"; x-sender="postmaster@mail-wi0-f173.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4DADCmb1LRVdStlGdsb2JhbABZgkN8wAaBJRYOAQEBAQcLCwkSKoIlAQEEAW0RCxIKAwECAS40AQUBEgIIGYgBBgQBCJpLlV+JFI1zGYEqDRGDGYENA55GiWBBhFE X-IPAS-Result: Ah4DADCmb1LRVdStlGdsb2JhbABZgkN8wAaBJRYOAQEBAQcLCwkSKoIlAQEEAW0RCxIKAwECAS40AQUBEgIIGYgBBgQBCJpLlV+JFI1zGYEqDRGDGYENA55GiWBBhFE X-IronPort-AV: E=Sophos;i="4.93,593,1378850400"; d="scan'208,217";a="32411183" Received: from mail-wi0-f173.google.com ([209.85.212.173]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Oct 2013 13:14:21 +0100 Received: by mail-wi0-f173.google.com with SMTP id ey11so5070215wid.12 for ; Tue, 29 Oct 2013 05:14:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:references:to :message-id:mime-version; bh=dTFiPqngSLvTSJx0LHGZJKgZJdB/+SKcYqo4gdgT6mM=; b=DqBCy9DQScztzERPD4cuLf+Pue2QTAzeWj43ICE5rSnSNE5IvuF2C6wwsAiQFQHQk7 d4mwMFs4ZcWEs+RtCOO9j2G+H13zBtZAsRY6qLvQzTQFHswGMCQNZKz+G5K41hnOWDfn OQGkT3PGhT7D/Or2sHXyE4u8m1b0yHHzt1KQGW9Rs0TQJlvctk0BNiGoo1b3SN/xu4GK 3HZju5uFrriIiQkLv6WNBrrnIhKzYZM8sV4hYZVeF73VwwFUPkO/Nwl5Ni/O1iygLZ1b weeWwsTBE7gOKsjOOiyOHW8QWiVZr54x0tVVgZmv+MrYZNMEIMhTU6XQUo+M+YPONvZr 3i/g== X-Gm-Message-State: ALoCoQkND8b4j92RcwuoguZnJK/4WW9x7eaHYkwFeX9FVVTT4OeIhPJWHe17EDIUqfNjoaNjeDfv X-Received: by 10.180.160.178 with SMTP id xl18mr13323346wib.61.1383048860926; Tue, 29 Oct 2013 05:14:20 -0700 (PDT) Received: from [172.20.10.8] (94.197.120.47.threembb.co.uk. [94.197.120.47]) by mx.google.com with ESMTPSA id q3sm4281119wib.5.2013.10.29.05.14.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 05:14:20 -0700 (PDT) From: Ollie Frolovs Content-Type: multipart/alternative; boundary="Apple-Mail=_9D648094-2E98-4CB8-90C7-541C477C7056" Date: Tue, 29 Oct 2013 12:14:16 +0000 References: <229046A9-C077-462E-903F-D3827D34B9A7@my.bristol.ac.uk> To: caml-list@inria.fr Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) X-Mailer: Apple Mail (2.1816) Subject: [Caml-list] Fwd: Using Uri with Google Distance Matrix API --Apple-Mail=_9D648094-2E98-4CB8-90C7-541C477C7056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is just a follow-up to say that i had used a workaround suggested by D= avid Sheets to resolve my issue with Uri. The Google Distance Matrix API service works when Uri replaces the pipe cha= racters with %7C. Since creating a request to API involves a rather inconvenient concatenatin= g of the arguments, i have made a suggestion to https://github.com/avsm/oca= ml-uri/issues/28 that an optional ~sep argument is introduced to Uri functi= ons, like the one in Jane Street=92s Core.String.concat. Many thanks, Ollie Begin forwarded message: > From: Ollie Frolovs > Subject: Re: [Caml-list] Using Uri with Google Distance Matrix API > Date: 29 October 2013 11:51:13 GMT > To: David Sheets >=20 >=20 > On 28 Oct 2013, at 22:26, David Sheets wrote: >=20 >> On Mon, Oct 28, 2013 at 9:58 PM, O Frolovs >> wrote: >>> Hello >>=20 >> Hi Ollie, > Hi David >=20 >>=20 >>> I'm learning OCaml and currently trying to use it for my project at uni. >>>=20 >>> Specifically, i=92m trying to use Uri [1] to create a Google Distance >>> Matrix request and i find it a bit awkward since the API uses pipe >>> character "|" for separating parameter values but Uri uses commas "," >>> and i could not find a way to override it: >>=20 >> Unfortunately, the Google Distance Matrix API does not conform to the >> Internet Standard for URIs. Specifically, the pipe character "|" is >> not allowed in a well-formed URI. I'm not sure why Google has decided >> to use this character out of the very many separators available to >> them. >=20 > This is very odd, indeed. >=20 >>=20 >>> utop # open Core.Std;; >>> utop # #require "uri";; >>>=20 >>> utop # let x =3D Uri.of_string "http://www.github.com/";; >>> val x : Uri.t =3D >>>=20 >>> utop # let y =3D Uri.add_query_param x ("origins", ["Bristol"; >>> "Cambridge"; "Plymouth"; "London"]);; >>> val y : Uri.t =3D >>>=20 >>> utop # Uri.to_string y;; >>> - : string =3D "http://www.github.com/?origins=3DBristol,Cambridge,Plym= outh,London" >>>=20 >>> This is not what the API expects. >>>=20 >>> I also tried concatenating the origins values before passing it to Uri >>> but as you can see below, Uri performed character escape on pipe >>> characters. So besides not looking elegant, it did not work: >>>=20 >>> utop # String.concat ~sep:"|" ["Bristol"; "Cambridge"; "Plymouth"; "Lon= don"];; >>> - : string =3D "Bristol|Cambridge|Plymouth|London" >>>=20 >>> utop # let y =3D Uri.add_query_param x ("origins", [c]);; >>> val y : Uri.t =3D >>>=20 >>> utop # Uri.to_string y;; >>> - : string =3D "http://www.github.com/?origins=3DBristol%7CCambridge%7C= Plymouth%7CLondon" >>>=20 >>> I am wondering >>>=20 >>> (a) if there is a way to make Uri do what i want, that is to use pipe >>> character to separate the origins values. >>=20 >> I do not believe there is a way to accomplish this in Uri 1.3.8. Have >> you tried submitting the percent-encoded query string to the API to >> see if Google properly interprets the escaping of invalid characters? >>=20 > I just tried this and it worked! Thanks for the suggestion. >=20 >> Uri is designed to take as input any string and produce as output only >> those strings that are conformant to RFC 3986. >>=20 >>> (b) why Uri does not have an optional ~sep parameter, like Jane >>> Street's Core.String.concat does? >>=20 >> No one has implemented it yet. :-) There has been discussion about >> significantly changing this API feature for 1.4 as well. >>=20 >> If you are not manipulating the URIs heavily and are not in need of >> input sanitation, using Uri may not be necessary unless another >> library requires input of Uri.t values. > I am using LWT and Cohttp which i believe requires Uri.t.=20 > So i am very happy the escaping worked with the API :) >=20 >> If none of this helps you, please create an issue at >> and we may end >> up adding something to help you in the next revision (could be later >> this week depending on how persuasive you are and how extensive the >> feature). > I will. I think the question here is how =91real-world=92 the Uri library= wants to be. > As an example =96 I do not know much about JSON yet, but i would expect > JSON libraries to make compromises to work with the real web services. > Otherwise, what good is the library if it only works with carefully chosen > artificial examples, RFC-compliant or not. >=20 >> Hope this helps, > It helped a lot, thanks again! :) >=20 > Regards, > Ollie --Apple-Mail=_9D648094-2E98-4CB8-90C7-541C477C7056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 This is just a follow-= up to say that i had used a workaround suggested by David Sheets to resolve= my issue with Uri.
The Google Distance Matrix API service works when U= ri replaces the pipe characters with %7C.
Since creating a reques= t to API involves a rather inconvenient concatenating of the arguments, i h= ave made a suggestion to https://github.com/avsm/ocaml-uri/issues/28 that an optional= ~sep argument is introduced to Uri functions, like the one in Jane Street= =92s Core.String.concat.

Many thanks, Ollie

Begin forwarded message:

From: Ollie Frolovs <of12343@my.bristol.ac.uk>
<= span style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);">Subjec= t: Re: [Caml-list] U= sing Uri with Google Distance Matrix API
= Date:= 29 October 2013 11:51:= 13 GMT
To: David Sheets <sheets= @alum.mit.edu>


On 28 Oct 2013, at 22:26, David Sh= eets <sheets@alum.mit.edu>= wrote:

On Mon, Oct 28, 2013 at 9:58 PM, O Frolovs
<ollie.frolovs.2012@my.bristol.ac.uk&g= t; wrote:
Hello

Hi Ollie,<= br>
Hi David


I'm learning OCaml and currently tryin= g to use it for my project at uni.

Specifically, i=92m trying to use= Uri [1] to create a Google Distance
Matrix request and i find it a bit = awkward since the API uses pipe
character "|" for separating parameter v= alues but Uri uses commas ","
and i could not find a way to override it:=

Unfortunately, the Google Distance Matrix API does not= conform to the
Internet Standard for URIs. Specifically, the pipe chara= cter "|" is
not allowed in a well-formed URI. I'm not sure why Google ha= s decided
to use this character out of the very many separators availabl= e to
them.

This is very odd, indeed= .


utop # open Core.Std;;
utop # #require "uri";;

ut= op # let x =3D Uri.of_string "http://www= .github.com/";;
val x : Uri.t =3D <abstr>

utop # let y = =3D Uri.add_query_param x ("origins", ["Bristol";
"Cambridge"; "Plymouth= "; "London"]);;
val y : Uri.t =3D <abstr>

utop # Uri.to_str= ing y;;
- : string =3D "http://www.github.com/?origins=3DBristol,Cam= bridge,Plymouth,London"

This is not what the API expects.
I also tried concatenating the origins values before passing it to Uri
= but as you can see below, Uri performed character escape on pipe
charact= ers. So besides not looking elegant, it did not work:

utop # String.= concat ~sep:"|" ["Bristol"; "Cambridge"; "Plymouth"; "London"];;
- : str= ing =3D "Bristol|Cambridge|Plymouth|London"

utop # let y =3D Uri.add= _query_param x ("origins", [c]);;
val y : Uri.t =3D <abstr>
utop # Uri.to_string y;;
- : string =3D "http://www.github.co= m/?origins=3DBristol%7CCambridge%7CPlymouth%7CLondon"

I am wonde= ring

(a) if there is a way to make Uri do what i want, that is to us= e pipe
character to separate the origins values.

I d= o not believe there is a way to accomplish this in Uri 1.3.8. Have
you t= ried submitting the percent-encoded query string to the API to
see if Go= ogle properly interprets the escaping of invalid characters?

<= /blockquote>
I just tried this and it worked! Thanks for the suggestion= .

Uri is designed to take as input any s= tring and produce as output only
those strings that are conformant to RF= C 3986.

(b) why Uri does not have an optio= nal ~sep parameter, like Jane
Street's Core.String.concat does?

No one has implemented it yet. :-) There has been discussion ab= out
significantly changing this API feature for 1.4 as well.

If y= ou are not manipulating the URIs heavily and are not in need of
input sa= nitation, using Uri may not be necessary unless another
library requires= input of Uri.t values.
I am using LWT and Cohttp whi= ch i believe requires Uri.t. 
So i am ver= y happy the escaping worked with the API :)
If none of this helps you, please create an iss= ue at
<https://github.com/mirage/ocaml-uri/issues?state=3Dopen> and w= e may end
up adding something to help you in the next revision (could be= later
this week depending on how persuasive you are and how extensive t= he
feature).
I will. I think the question here is = how =91real-world=92 the Uri library wants to be.
As an example =96 I do not know much about JSON yet, but i would expect=
JSON libraries to make compromises to work wi= th the real web services.
Otherwise, what good= is the library if it only works with carefully chosen
artificial examples, RFC-compliant or not.

Hope this helps,
It h= elped a lot, thanks again! :)

Regards,
Ollie

= --Apple-Mail=_9D648094-2E98-4CB8-90C7-541C477C7056--