From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Julien Danjou Newsgroups: gmane.emacs.devel Subject: Re: more url-utils? Date: Mon, 16 May 2011 21:52:43 +0200 Message-ID: <87k4dqtoc4.fsf@keller.adm.naquadah.org> References: <8739kgqbui.fsf@gnu.org> <871uzy7b9o.fsf@lifelogs.com> <877h9q5ub7.fsf@lifelogs.com> <87y6264f29.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: dough.gmane.org 1305575616 21751 80.91.229.12 (16 May 2011 19:53:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 16 May 2011 19:53:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 16 21:53:31 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QM3r5-0004QO-2a for ged-emacs-devel@m.gmane.org; Mon, 16 May 2011 21:53:27 +0200 Original-Received: from localhost ([::1]:35112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QM3r4-0003hh-Lt for ged-emacs-devel@m.gmane.org; Mon, 16 May 2011 15:53:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QM3r2-0003hZ-Ta for emacs-devel@gnu.org; Mon, 16 May 2011 15:53:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QM3r0-0003So-GF for emacs-devel@gnu.org; Mon, 16 May 2011 15:53:24 -0400 Original-Received: from prometheus.naquadah.org ([212.85.154.174]:54247 helo=mx1.naquadah.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QM3r0-0003Sf-A9 for emacs-devel@gnu.org; Mon, 16 May 2011 15:53:22 -0400 Original-Received: from keller.adm.naquadah.org (keller.adm.naquadah.org [192.168.2.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.naquadah.org (Postfix) with ESMTPSA id 13FA25C0A6; Mon, 16 May 2011 21:53:20 +0200 (CEST) Mail-Followup-To: Ted Zlatanov , emacs-devel@gnu.org In-Reply-To: <87y6264f29.fsf@lifelogs.com> (Ted Zlatanov's message of "Mon, 16 May 2011 14:32:14 -0500") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 212.85.154.174 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139440 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, May 16 2011, Ted Zlatanov wrote: > I'm trying to avoid that approach: we just established the headers are > almost never necessary in the buffer. So we should not ask the API > users to do anything extra to remove them. That can be true. When you fetch an URL, you want to know if the fetch result is a 200 OK or a 404 Not Found. That's the absolute minimum thing you want to do if you plan to write correct code. So just dropping the header sounds like a very bad programming practice, and not something I'd encourage. I wrote code with url.el. And what I always did is (search-forward "\n\n") to move point between headers and content, and then parse the headers to at least check the return code (expecting 200 usually). I often also needed the Content-Type (so clearly an alist of parsed headers would be welcome). =2D-=20 Julien Danjou =E2=9D=B1 http://julien.danjou.info --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJN0YCLAAoJEGEbqVCLeKXCGoUP/ivSnlAE4AXp1kwMekB57IME AGeg2bCev0BJnKq5YfkbgU/mY0RG+qOP6NVSPy9wbJCBwju3dIf4HPmwDEObcxNM qjAfxuJzG3L3t8biWuao2eSCHox04HMp2fGqX5SoxEBpdyif7wp7sAn8I1xQ3rSh cckAM16IiWDeSlDvWdIH1VjlKThGLXZOR7w9KcuyubdIfV94y3Iz9hlo1UNkeX/m H/eBRfHCe9h8BA5zMG/Gb0zogM9vS0/wHwP6XJpkzRb3mxLfBOEmyWOXXhTR4o8F CnLSf/egbAB5z/X7tXUuXwo4VBme0Oi8vOsH6S+1EpIYOilpx6JxPphZH3MdvuLT 0RnhMyQEinK3CY+mDCFIO9/ZYjnnbuNc8B8Tkebribbefw/Uf6bl+IZJ9zFAXGkH rhbBqTBW+Kf7jTB9Pl2RR/Ebm8scz/BTvxEDQX9XvkJ7ZX61BJmyBcctkuF5/bAg ix4rWQWyQIpBy8DV5OmyUYHj/uZLYa0fRHz72YfoN4gNvNi97Jfgj1LEGPwVKJsF 5LtpPmykZj6QltAGGdosvCiLGepUgJzKIHGBK57hNsbs9X5BLRdem+jXApMVFX7A 53mdpSz4DBEfuj6Fp36c2EHdWTUOPblNAmQdPNYK5tOHWwOZ80oAWZL9PETWPcwb jmTF8NeTUobrlcxFnlqj =4Q9O -----END PGP SIGNATURE----- --=-=-=--