[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more url-utils?

From: Ted Zlatanov
Subject: Re: more url-utils?
Date: Mon, 16 May 2011 15:18:53 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

On Mon, 16 May 2011 21:52:43 +0200 Julien Danjou <address@hidden> wrote: 

JD> 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.

JD> That can be true. When you fetch an URL, you want to know if the fetch
JD> result is a 200 OK or a 404 Not Found. That's the absolute minimum thing
JD> you want to do if you plan to write correct code.
JD> So just dropping the header sounds like a very bad programming practice,
JD> and not something I'd encourage.

You won't get a HTTP status (or any headers, sometimes) from a non-HTTP
URL.  So the status is only useful in some cases and relying on it makes
the code inflexible, depending on the transport protocol's artifacts.

JD> I wrote code with url.el. And what I always did is (search-forward
JD> "\n\n") to move point between headers and content, and then parse the
JD> headers to at least check the return code (expecting 200 usually).

That's a symptom of a bad API that tied you to HTTP headers and what I
was trying to eliminate.

On Mon, 16 May 2011 16:53:37 -0300 Stefan Monnier <address@hidden> wrote: 

>>>> After looking at many examples in Emacs, I can't find or think of any
>>>> need for the headers *as text* in the code I've seen.  I would:
SM> That sounds right.
>> ...so can I go ahead with my proposal or would you rather be
>> conservative and keep the old behavior, making API users turn off
>> headers explicitly?

SM> There are 3 parts.
SM> - removal of header text.
SM> - backward compatibility.
SM> - providing header info in a non-textual format.

Ah, OK.  So my proposal does not fit because you want backwards
compatibility.  I was hoping to eliminate the bad API altogether but
this is at least a step forward.  Let me know if you want me to
implement any parts of this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]