Dimitre Liotev | 3 Sep 2008 04:27

END-OF-FILE error


When trying this:

(drakma:http-request "http://news.ycombinator.com/rss")

I get and end-of-file error. I can pull this page with curl and
firefox, and can't figure out the problem with Drakma. Any ideas?

--

-- 
Dimitre Liotev
Edi Weitz | 3 Sep 2008 08:44
Picon
Favicon

Re: END-OF-FILE error

On Tue, 02 Sep 2008 22:27:45 -0400, Dimitre Liotev <dl <at> znain.net> wrote:

> When trying this:
>
> (drakma:http-request "http://news.ycombinator.com/rss")
>
> I get and end-of-file error.

  http://weitz.de/drakma/#prob
Dimitre Liotev | 4 Sep 2008 03:27

Re: END-OF-FILE error

Edi Weitz <edi <at> agharta.de> writes:

> On Tue, 02 Sep 2008 22:27:45 -0400, Dimitre Liotev <dl <at> znain.net> wrote:
>
>> When trying this:
>>
>> (drakma:http-request "http://news.ycombinator.com/rss")
>>
>> I get and end-of-file error.
>
>   http://weitz.de/drakma/#prob

Thanks!
Milan Cermak | 9 Sep 2008 17:35
Picon

digest authentication

Hi,

is anybody planning to add digest authentication do Drakma in the near future (say, 1 month)? If not, I would do it myself, because I need it. However it would be a poor's man implementation, not the whole RFC. I'd appreciate some tips how to integrate the functionality into the Drakma source code so I can send a clean patch, not just a dirty hack (I already know about http://weitz.de/patches.html).

Milan


_______________________________________________
drakma-devel mailing list
drakma-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
Milan Cermak | 9 Sep 2008 17:25
Picon

digest authentication

Hi,

is anybody planning to add digest authentication do Drakma in the near future (say, 1 month)? If not, I would do it myself, because I need it. However it would be a poor's man implementation, not the whole RFC. I'd appreciate some tips how to integrate the functionality into the Drakma source code so I can send a clean patch, not just a dirty hack (I already know about http://weitz.de/patches.html).

Milan
_______________________________________________
drakma-devel mailing list
drakma-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
Edi Weitz | 9 Sep 2008 19:57
Picon
Favicon

Re: digest authentication

On Tue, 9 Sep 2008 17:35:44 +0200, "Milan Cermak" <milan <at> soci.ali.sm> wrote:

> However it would be a poor's man implementation, not the whole RFC.

Hi!

I tend to think that if it goes into the source it should implement
the whole RFC or at least a very clearly defined subset which is
of interest to more than one person.

Thanks,
Edi.
Milan Cermak | 10 Sep 2008 12:15
Picon

Re: digest authentication



On Tue, Sep 9, 2008 at 7:57 PM, Edi Weitz <edi <at> agharta.de> wrote:
On Tue, 9 Sep 2008 17:35:44 +0200, "Milan Cermak" <milan <at> soci.ali.sm> wrote:

> However it would be a poor's man implementation, not the whole RFC.

Hi!

I tend to think that if it goes into the source it should implement
the whole RFC or at least a very clearly defined subset which is
of interest to more than one person.

I can do just WWW-Authenticate. I don't need Proxy-Authenticate.

_______________________________________________
drakma-devel mailing list
drakma-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
Zach Beane | 10 Sep 2008 15:20
Gravatar

Sending content without loading it all in memory?

Is there any way to send a non-chunked request without having the
entire content in memory at once?

I'm working on an Amazon S3 client based on Drakma, but sometimes I
want to upload (via PUT) very large files and I'd prefer to determine
the content-length via FILE-LENGTH and upload the body
buffer-by-buffer instead of all at once.

Zach
Edi Weitz | 10 Sep 2008 17:03
Picon
Favicon

Re: Sending content without loading it all in memory?

On Wed, 10 Sep 2008 09:20:30 -0400, Zach Beane <xach <at> xach.com> wrote:

> Is there any way to send a non-chunked request without having the
> entire content in memory at once?

You can set the content length header yourself.  In that case Drakma
shouldn't use chunked encoding IIRC.

  http://weitz.de/drakma/#content-length

> I'm working on an Amazon S3 client based on Drakma, but sometimes I
> want to upload (via PUT) very large files and I'd prefer to
> determine the content-length via FILE-LENGTH and upload the body
> buffer-by-buffer instead of all at once.

That should be no problem if you provide a function as the :content
keyword argument or use the "continuation" facility.

Cheers,
Edi.
Zach Beane | 10 Sep 2008 17:07
Gravatar

Re: Sending content without loading it all in memory?

On Wed, Sep 10, 2008 at 05:03:33PM +0200, Edi Weitz wrote:
> On Wed, 10 Sep 2008 09:20:30 -0400, Zach Beane <xach <at> xach.com> wrote:
> 
> > Is there any way to send a non-chunked request without having the
> > entire content in memory at once?
> 
> You can set the content length header yourself.  In that case Drakma
> shouldn't use chunked encoding IIRC.
> 
>   http://weitz.de/drakma/#content-length

Unfortunately that's not the case, as the documentation says:

| A non-NIL content-length argument means that Drakma must build the
| request body in RAM and compute the content length even if it would
| have otherwise used chunked encoding - for example in the case of
| file uploads.

The code says it too:

   (when (and content-length
	      (not (or (arrayp content)
		       (listp content)
		       (eq content :continuation))))
     ;; CONTENT-LENGTH forces us to compute request body
     ;; in RAM
     ...)

> > I'm working on an Amazon S3 client based on Drakma, but sometimes I
> > want to upload (via PUT) very large files and I'd prefer to
> > determine the content-length via FILE-LENGTH and upload the body
> > buffer-by-buffer instead of all at once.
> 
> That should be no problem if you provide a function as the :content
> keyword argument or use the "continuation" facility.

I tried that too, but:

  (when (and (eq content :continuation) content-length)
    (error "CONTENT-LENGTH must be NIL if CONTENT is :CONTINUATION."))

I think I might be out of luck.

Zach

Gmane