Re: [Lurker-users] Lurker and (https|mailto:-links)

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Wesley W. Terpstra
Date:  
To: Stephan Berndts
CC: Lurker Users
Subject: Re: [Lurker-users] Lurker and (https|mailto:-links)
On Tue, Dec 23, 2003 at 01:35:55AM +0100, Stephan Berndts wrote:
> You -- Wesley -- state (in your 1.0 release announce;
> http://lurker.sourceforge.net/archive/message/20030703.170811.eb664ec5.html)
> that Lurker 1.0 supports the Opera webbrowser.


Well, it worked for me (TM).
I admit that I didn't try using SSL though.

> It does not, at least partially not:
>
> Lurker inserts attributes like
> onClick="self.location='http://host:port/path';" into links to a
> message.
> That's not beautiful for http over port 80 as it is not necessary and
> lengthens the url shown in the addressbar.


Sadly it is necessary... As far as my testing showed, a relative url does
not work with self.location='/blah.html' . If you can suggest alternative
javascript I will happily integrate this change.

However, lurker cgis for keyword search and date jump also use an absolute
URL during redirection. Again, this is required; the HTTP RFC requires me to
use an absolute url. Some browsers work with relative, but some don't.

> It prevents Opera users from using Lurker with https over port 443 as
> opera does not accept urls like 'http://host:443/path' as a security
> feature -- which is not configurable yet.


I see.

Seems to me that this is a slightly different sort of bug. :-)
If I had said https://host:443/path it would have worked.
(Could you verify this by changing the html by hand?)

I think my code is just brainlessly inserting 'http' into the URL.
I can't believe no one else has caught this!

Anyways, I would take this to mean that lurker 1.0 and ssl don't work
together and nothing at all to do with opera.

> And second: more a feature request than a question: Really simple the
> possibility to avoid mailto:-links and the displaying of mail
> addresses. At least those which point to the sender of a mail.
> I do not think that I have to elaborate on the reasons for this
> request.


That's a good feature indeed...
For senders and recipients without a personal name, how about I only include
the username (with @host)? Otherwise, just the personal name. I guess I
should cut it out at the XML level too in case spammers are clever.

I think both of these changes and a pair of other bugfixes I've amassed
would make a worthy 1.1 since they don't break compatibility.

--
Wesley W. Terpstra