From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id AFB83BC6B for ; Sun, 30 Sep 2007 18:45:19 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMZt/0bU436ui2dsb2JhbACOMQEBAQgEBg0a X-IronPort-AV: E=Sophos;i="4.21,213,1188770400"; d="scan'208";a="2100734" Received: from moutng.kundenserver.de ([212.227.126.174]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Sep 2007 18:45:19 +0200 Received: from [84.59.99.108] (helo=gate.lan.gerd-stolpmann.de) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1Ic1uw1Yrc-0002Dk; Sun, 30 Sep 2007 18:45:18 +0200 Received: from flakew.lan.gerd-stolpmann.de (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 25487C0AD; Sun, 30 Sep 2007 18:45:18 +0200 (CEST) Subject: Re: [Caml-list] cookies in netclient From: Gerd Stolpmann To: Hendrik Tews Cc: caml-list@yquem.inria.fr In-Reply-To: References: <18127.20625.317597.197268@tandem.cs.ru.nl> <1188253645.7533.15.camel@localhost.localdomain> <1188310360.7533.51.camel@localhost.localdomain> Content-Type: text/plain Date: Sun, 30 Sep 2007 18:45:17 +0200 Message-Id: <1191170717.7114.39.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+nzpAUQ82Fs7lWoBl8Y68cxCBj6608CrBSLVy c3c0DeEyXdNLQrxpYpmgn71F/wIwGDaHm6crAESTNiun/3wGp6 lqIWAQYV7Id2MEB9SiSOy/iMgiXkWoK X-Spam: no; 0.00; netclient:01 gerd:01 stolpmann:01 hendrik:01 tews:01 gerd:01 stolpmann:01 encodings:01 netencoding:01 params:01 params:01 ocamlnet:01 ocamlnet:01 viktoriastr:01 64293:01 Am Freitag, den 28.09.2007, 11:49 +0200 schrieb Hendrik Tews: > Gerd Stolpmann writes: > > > Unfortunately, get_set_cookie is missing (I have an implementation if > > you really need it). > > > > This one would retrieve the cookies as an Nethttp.cookie list? I > > don't know yet if I need it. > > yes. You find it if you need it: > > https://godirepo.camlcity.org/wwwsvn/trunk/code/get-set-cookie.ml?rev=1145&root=lib-ocamlnet2&view=auto > > > In my opinion it would be more convenient to have something of > type > > #Nethttp.http_header_ro -> Nethttp.cookie list > > eg > > let get_set_cookies mh = > List.map get_set_cookie (mh#multiple_field "set-cookie") Right. Please keep in mind that the posted function is just an extraction of a bigger program, and I didn't need more there. > Further I propose to add a function to set cookies that accepts a > cookie list, like > > let set_cookies mh l = > Nethttp.Header.set_cookie mh > (List.map (fun c -> (c.Nethttp.cookie_name, c.Nethttp.cookie_value)) l) I usually resist to include such convenience functions since (a) they are ultimately simple and (b) the docs would be longer than the function. > The docs for http_call#request_header says > > The user should set the following headers: > > * Content-length: Set this to the length of the request body > if known. (The client falls back to HTTP 1.0 if not set!) > > Do I have to care about this when using > Nethttp.Header.set_cookie? I don't understand. The problem with Content-length is the following. Older HTTP versions (i.e. 1.0) did not have a way to transfer request messages with unknown length other than sending EOF. That means you can only indicate the end of the request by closing the sending part of the connection. Although HTTP 1.1 fixes that problem, a client simply cannot know whether it talks to a 1.0 or a 1.1 server, so you have to be 1.0-compatible. And that means to either include the Content-length header, or to accept the EOF. (And there are still many 1.0-only servers around!) Of course, this does not have anything to do with cookies. > >From what I read in the docs, it was not clear to me if > #request_header returns a copy of the header. I.e. do I have to > #set_request_header after modifying the header? (It works > without, so I guess #request_header does not copy.) Yes, it is not a copy. > Yet another question: The docs for Netmime.mime_body_ro#value > says it will return the decoded body. That means that any Base-64 or quoted-printable encoding is automatically decoded. These encodings are only used for mail messages, and not for HTTP. > But in which encoding? For > instance, if I want to extract pieces of an html page, what > should I pass as in_enc:Netconversion.encoding to > Netencoding.Html.decode? (At the moment decode_to_latin1 works > fine with me, but that's probably not the right way.) The character encoding is a different thing. It can be sent in two ways: If there is a Content-type header in the response with a charset parameter, this one counts. This looks like Content-type: text/html;charset=euc-kr but the grammar allows more complex expressions as well. Use the #content_type method of the response header to parse it, e.g. let ct, ct_params = http_call#response_header#content_type in let charset = List.assoc "charset" ct_params in let charset_s = Mimestring.param_value charset in ... If you get Not_found by List.assoc, there is a second way to get the character encoding. The HTML document may contain There is unfortunately no other way than to HTML-parse the document and look for this element (Nethtml should do well). If this method also fails, there is no clean way of determining the character encoding. Browsers usually fall back to something called "auto-recognition" but it works only if you know the language (e.g. if you know it is Japanese these algorithms can distinguish euc-jp from Shift-JIS). There is no auto-recognition implementation in ocamlnet. > Ocamlnet works now fine for me: Thanks for this great package! Great to hear it! Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------