Edi Weitz | 10 Jul 2010 12:06
Picon
Favicon

New Drakma release 1.2.2

There's a new release of Drakma out at weitz.de.  This is a bugfix release.

ChangeLog: http://weitz.de/drakma/CHANGELOG.txt
Walter GR | 12 Jul 2010 01:29
Picon
Favicon

Patch: Unclosed <code> node in doc/index.html

Patch attached.

An unclosed <code> node in doc/index.html causes all text after the 
documentation for *allow-dotless-cookie-domains-p* to render in a 
monospaced font.

This is my first patch ever, so let me know if I did it wrong.

Thanks,

Walter

--

-- 
The Online Slang Dictionary - Now a wiki!
http://onlineslangdictionary.com/
Attachment (drakma-doc.patch): text/x-patch, 617 bytes
_______________________________________________
drakma-devel mailing list
drakma-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
Edi Weitz | 12 Jul 2010 22:46
Picon
Favicon

Re: Patch: Unclosed <code> node in doc/index.html

Thanks for the patch, I've fixed this in the repository and on the
website.  Will be in the next release.

(It seems, Firefox doesn't have a problem with this glitch, though.)

On Mon, Jul 12, 2010 at 1:29 AM, Walter GR <waltergr <at> aol.com> wrote:
> Patch attached.
>
> An unclosed <code> node in doc/index.html causes all text after the
> documentation for *allow-dotless-cookie-domains-p* to render in a monospaced
> font.
>
> This is my first patch ever, so let me know if I did it wrong.
>
> Thanks,
>
> Walter
>
>
> --
> The Online Slang Dictionary - Now a wiki!
> http://onlineslangdictionary.com/
>
> _______________________________________________
> drakma-devel mailing list
> drakma-devel <at> common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>
>
(Continue reading)

Walter GR | 14 Jul 2010 08:42
Picon
Favicon

Re: Patch: Unclosed <code> node in doc/index.html

 > (It seems, Firefox doesn't have a problem with this glitch, though.)

I was remiss in not mentioning: I'm using Chrome 5 on XP.  Apple Safari 
uses the same rendering engine, but I don't have an installation handy 
to test on.

Walter

On 7/12/2010 1:46 PM, Edi Weitz wrote:
> Thanks for the patch, I've fixed this in the repository and on the
> website.  Will be in the next release.
>
> (It seems, Firefox doesn't have a problem with this glitch, though.)
>
> On Mon, Jul 12, 2010 at 1:29 AM, Walter GR<waltergr <at> aol.com>  wrote:
>>  Patch attached.
>>
>>  An unclosed<code>  node in doc/index.html causes all text after the
>>  documentation for *allow-dotless-cookie-domains-p* to render in a monospaced
>>  font.
>>
>>  This is my first patch ever, so let me know if I did it wrong.
>>
>>  Thanks,
>>
>>  Walter
>>
>>
>>  --
>>  The Online Slang Dictionary - Now a wiki!
(Continue reading)

Herbert Snorrason | 21 Jul 2010 15:28
Picon

Regarding URL encoding...

Although I understand why it's not done by default, it seems slightly
odd to me that Drakma doesn't provide a URL-ENCODE function whereas
Hunchentoot does. I would've thought the need was considerably more
immediate in Drakma...

With greetings,
  Herbert Snorrason
Herbert Snorrason | 21 Jul 2010 17:46
Picon

Re: Regarding URL encoding...

On 21 July 2010 13:28, Herbert Snorrason <methanal <at> gmail.com> wrote:
> [...] Drakma doesn't provide a URL-ENCODE function [...]
And after thinking about it, turns out it _does_, just doesn't expose
it. The thinking is, I presume, that all URL-encoded data should pass
through another interface that handles the cleaning?

In any case, the attached patch updates url-encode to RFC3986 (or at
least only passes that standard's "unreserved characters" through) and
exposes it.

With greetings,
  Herbert Snorrason
Attachment (url-encode.diff): text/x-diff, 2946 bytes
_______________________________________________
drakma-devel mailing list
drakma-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
Joshua TAYLOR | 21 Jul 2010 18:24
Picon
Favicon

Re: Regarding URL encoding...

On Wed, Jul 21, 2010 at 11:46 AM, Herbert Snorrason <methanal <at> gmail.com> wrote:
> In any case, the attached patch updates url-encode to RFC3986 (or at
> least only passes that standard's "unreserved characters" through) and
> exposes it.

I suspect that the original portions of

-                        (find char "$-_.!*'()," :test #'char=))
+                        (find char "-_.~" :test #'char=))
                      (write-char char out))
-                   ((char= char #\Space)
-                     (write-char #\+ out))

are based on RFC 1738's more restricted list of characters:

   Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
   reserved characters used for their reserved purposes may be used
   unencoded within a URL. [1]

Since request parameters (which could include URIs) might appear in
the HTTP request's URL, the parameters need to be URL encoded, not
just composed of valid URI characters.

[1] http://www.rfc-editor.org/rfc/rfc1738.txt

//JT

--

-- 
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
(Continue reading)

Vsevolod Dyomkin | 29 Jul 2010 11:22
Picon
Gravatar

Re: duplicate cookies problem with proposed patch

Hi,

I want to re-raise the topic of duplicate cookies.  I've had this issue with the older version of Drakma (1.1.0) and was unaware of the patch with *remove-duplicate-cookies-p*.
But investigating the problem (before I've read the discussion in the mailing list), I've encountered it's cause in the source code, that is highlighted in the attached diff.  The problem is, that SET-DIFFERENCE and UNION are not supplied COOKIE= tests in UPDATE-COOKIES.

It still remains in the current version (1.2.2) and can be tested like this:

CL-USER> (defvar *cookies* (make-instance 'drakma:cookie-jar))
*COOKIES*
CL-USER> (drakma::update-cookies (list (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/")
                                      (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/"))
                                *cookies*)
#<DRAKMA:COOKIE-JAR (with 2 cookies) {B629521}>


I think, that this is a bug, because without the TEST argument, for example, SET-DIFFERENCE in this case will constantly return the first set (see below), so either the code should be simplified or the test argument should be added.

CL-USER> (set-difference (list (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/")
                              (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/"))
                        (list (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/")
                              (make-instance 'drakma:cookie :name "lang" :value "en" :domain "site.com" :path "/")))
(#<DRAKMA:COOKIE lang=en; path=/; domain=site.com>
 #<DRAKMA:COOKIE lang=en; path=/; domain=site.com>)

So, I believe, that this part should also be fixed, especially, since UPDATE-COOKIES is called alongside with GET-COOKIES.

Best regards,
Vsevolod
Attachment (cookies.diff): text/x-patch, 563 bytes
_______________________________________________
drakma-devel mailing list
drakma-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel

Gmane