From reddaly at gmail.com  Fri Feb  5 10:03:29 2010
From: reddaly at gmail.com (Red Daly)
Date: Fri, 5 Feb 2010 02:03:29 -0800
Subject: [drakma-devel] Patch - Accept-Encoding: gzip
In-Reply-To: <b56421a01001251252r58d52e4elbd627e6e8305cfcf@mail.gmail.com>
References: <f6700f0c1001210157p539fde29n96a8c4615b90eb87@mail.gmail.com>
	<b56421a01001251252r58d52e4elbd627e6e8305cfcf@mail.gmail.com>
Message-ID: <f6700f0c1002050203y6c6a2544m86c8c9fe0789b0a4@mail.gmail.com>

Hi Edi,

This started off as a simple wrapper around a drakma call, but I found
it handy enough that I used it in a few different places.  Since
Drakma is a non-trivial HTTP client, I thought it might be
appropriate.  Next time I have a chance I will hookify the patch

On Mon, Jan 25, 2010 at 12:52 PM, Edi Weitz <edi at agharta.de> wrote:
> Hi Red,
>
> Thanks for the patch. ?(But note the guidelines at
> <http://weitz.de/patches.html>...)

I thought I obeyed most of them except for "If you're going to send a
patch which makes significant changes, ask me first if I'm actually
willing to integrate your changes before you end up doing a lot of
work in vain."  Just for future reference--did I miss anything else?


>
> I'm unsure whether I want to accept the patch, though. ?I don't really
> want to add a dependency on another library which in turn depends on
> another library for a pretty rare case. ?I'd rather implement a hook
> or something so that Drakma users can pre-process the content
> externally.
>
> Cheers,
> Edi.


Thanks for the libraries!

Red

>
>
> On Thu, Jan 21, 2010 at 10:57 AM, Red Daly <reddaly at gmail.com> wrote:
>> Dear drakma users,
>>
>> I made drakma accept gzipped message bodies by default, and also
>> automatically decode them. ?A patch is attached.
>>
>> Unfortunately this adds a new dependency on gzip-sequence (which in
>> turn depends on salza2). ?See the docstrings for more details. ?To sum
>> it up: if WANT-STREAM is T, It wraps the returned stream in a
>> flexi-stream that wraps a gzip-input-stream. ?Otherwise, it decodes
>> the sequence before returning from HTTP-REQUEST.
>>
>> Thanks,
>> Red
>>
>> _______________________________________________
>> drakma-devel mailing list
>> drakma-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>>
>>
>
> _______________________________________________
> drakma-devel mailing list
> drakma-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>



From edi at agharta.de  Fri Feb  5 10:29:06 2010
From: edi at agharta.de (Edi Weitz)
Date: Fri, 5 Feb 2010 11:29:06 +0100
Subject: [drakma-devel] Patch - Accept-Encoding: gzip
In-Reply-To: <f6700f0c1002050203y6c6a2544m86c8c9fe0789b0a4@mail.gmail.com>
References: <f6700f0c1001210157p539fde29n96a8c4615b90eb87@mail.gmail.com>
	<b56421a01001251252r58d52e4elbd627e6e8305cfcf@mail.gmail.com>
	<f6700f0c1002050203y6c6a2544m86c8c9fe0789b0a4@mail.gmail.com>
Message-ID: <b56421a01002050229h1fc2979es263dc4acebde1194@mail.gmail.com>

On Fri, Feb 5, 2010 at 11:03 AM, Red Daly <reddaly at gmail.com> wrote:
> Next time I have a chance I will hookify the patch

Good.  Looking forward to that.

> I thought I obeyed most of them except for "If you're going to send a
> patch which makes significant changes, ask me first if I'm actually
> willing to integrate your changes before you end up doing a lot of
> work in vain." ?Just for future reference--did I miss anything else?

There were TABs in the patch, and the HTML documentation wasn't updated IIRC.

Thanks,
Edi.



From youngde811 at gmail.com  Wed Feb 24 20:51:44 2010
From: youngde811 at gmail.com (David Young)
Date: Wed, 24 Feb 2010 15:51:44 -0500
Subject: [drakma-devel] DelegationFailure with Amazon CloudWatch
Message-ID: <fe95bc501002241251s111968d9o28357aa4dc03ce54@mail.gmail.com>

Hi. I really doubt this is a drakma issue but Amazon has been of no help.
I've written a Lisp interface to the EC2 Query API
(CL-EC2<http://common-lisp.net/project/cl-ec2/>);
it uses Drakma has its http client. All of the implemented API calls work
just fine with the exception of the Cloudwatch ListMetrics call, which for
some reason began failing this week. Amazon's cloudwatch scratchpad tool
fails now also with the same error, but I tried the python boto library and
it works fine, as does the Amazon command-line tool mon-list-metrics.

Here's the header output:

SIERRA(29): (ec2:with-header-stream () (cw:list-metrics))
GET /?AWSAccessKeyId=<our access
key>?Action=ListMetrics&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2010-02-24T20%3A46%3A25Z&Version=2009-05-15&Signature=BHAB8OAeGU6IRp6Ki%2BDuEKM9%2FOiKKOSu%2FGntICOotqI%3D
HTTP/1.1
Host: monitoring.amazonaws.com
User-Agent: Drakma/1.1.0 (SBCL 1.0.30; Linux;
2.6.30.10-105.2.16.fc11.x86_64; http://weitz.de/drakma/)
Accept: */*
Connection: close

HTTP/1.1 400 Bad Request
x-amzn-RequestId: ac7304ba-2185-11df-a0eb-cd40a3846a7b
Content-Type: text/xml
Content-Length: 270
Date: Wed, 24 Feb 2010 20:46:25 GMT

And here's the condition as reported by our library:

Amazon EC2 Error: Bad Request:
 status: 400
 uri: http://monitoring.amazonaws.com?AWSAccessKeyId=<our access
key>&Action=ListMetrics&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2010-02-24T20%3A46%3A25Z&Version=2009-05-15&Signature=BHAB8OAeGU6IRp6Ki%2BDuEKM9%2FOiKKOSu%2FGntICOotqI%3D
 headers: ((X-AMZN-REQUESTID
            . ac7304ba-2185-11df-a0eb-cd40a3846a7b)
           (CONTENT-TYPE . text/xml) (CONTENT-LENGTH . 270)
           (DATE . Wed, 24 Feb 2010 20:46:25 GMT))
 body: ((ErrorResponse xmlns
         http://monitoring.amazonaws.com/doc/2009-05-15/)
        (Error (Type Sender) (Code DelegationFailure)
         (Message Malformed token))
        (RequestId ac7304ba-2185-11df-a0eb-cd40a3846a7b))

  [Condition of type EC2:EC2-ERROR]

I'm just looking for some ideas, so forgive me if I've bothered anyone. What
the hell is a DelegationFailure anyway? Sorry to trouble you folks. Thanks.

-- david

--
And now these three remain: faith, hope, and love.
But the greatest of these is love.
 -- 1 Corinthians 13:13

To truly engage with how the world is, our hearts
are going to be broken again and again.
 -- Rob Bell, "Velvet Elvis, Repainting the Christian Faith"

To produce without possessing, to work without expecting,
to enlarge without usurping. This is the supreme virtue.
-- Lao-Tzu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/drakma-devel/attachments/20100224/d529270e/attachment.html>