new libURL?

[Dave Cragg]

On 29 Sep 2004, at 21:00, Richard Gaskin wrote:

> Robert Brenstein wrote:
>>> Anyone have a URL to the latest version of LibURL which is 
>>> compatible with the latest engine?
>>>
>>> I can reconstruct one from dissecting Rev, but I'd rather use the 
>>> one from the official download URL.  That is, if there is an 
>>> official download URL. :)
>> Wasn't the url for download just recently posted here by the author?
>
> I couldn't find it in the archives, nor at the RunRev FTP site.  All I 
> know is it's no longer at the URL RunRev pulled from their site 
> without notice or forwarding address.
>
> If you have it handy it would be much appreciated.
>
I'm pretty sure I posted this here, but perhaps not.

Anyway, below is what I should have posted.

If you need exactly the version that went out with Rev 2.5, let me know 
and I'll send it to you.

I'm not sure what's going on with the RunRev site. I'm waiting to hear 
about organizing official downloads. But I'm happy to make things 
available on my own site meanwhile. I've been a bit lax about keeping 
on top of things recently. After moving out of town a few months ago, 
I've been stuck on a dial-up shared with my work phone. So getting the 
various Rev updates has been a pain. But today I got a satellite 
brodband connection fitted (the house now looks like a military 
installation) so I don't have that excuse anymore (at least I won't 
when I figure out how the firewall and such on the new gear works.)

BTW, have you had any more thoughts on how to handle the "split" 
versions of libUrl we now have for the MC IDE? I've had second thoughts 
about the idea I put up before about keeping the two stacks as custom 
properties and loading the one that's needed. It would make the stacks 
fairly inaccessible for those who wanted to view and edit them.

Cheers
Dave



----------------------------------------------
Hi all

I've just uploaded an updater for libUrl 1.1.1b1 (1.0.16b1) for 
testing. It addresses some of the recent issues brought up on this 
list.

You can get it drectly by typing this in the message box:

   go stack url 
"http://www.lacscentre.co.uk/liburl/updaters/liburl_1_1_1b1.rev"

Or download directly from your browser:

   http://www.lacscentre.co.uk/liburl/updaters/liburl_1_1_1b1.rev

or a zip version (much smaller and will overcome any issues of the 
above url appearing as a bunch of text in the browser)

   http://www.lacscentre.co.uk/liburl/updaters/liburl_1_1_1b1.rev.zip

Be sure to save a copy of revlibrary.rev (or mctools.mc for Metacard 
users) before running the updater.

I hope to put up documentation later, but here are some quick notes:

The updater will install the version of libUrl appropriate to your 
engine. For engine versions less than 2.6.1, you'll get libUrl 
1.0.16b1. Otherwise you'll get 1.1.1b1.

Changes (from the version shipping with Rev 2.5, which is 1.1b2)

In both 1.0.16b1 and 1.1.1b1

--  Fixes the libUrlDownloadToFile bug where the file wasn't closed 
properly.

--  Adds a libraryStack handler (mainly for Metacard users)

-- Adds a new command libUrlFollowHttpRedirects <true|false> (Default 
is true)

   When set to true (the default), libUrl will respond to 301, 302, and 
307 responses by trying to get the url listed in the Location header IF 
the original request was a GET (i.e not a post). It will respond to 303 
responses by trying to GET the redirected url whatever the original 
request method.  When set to false, no attempt is made to get the 
redirected url and the result will return "error" followed by the 
status code and message (e.g. error 302 found)

This is different from the current behavior whereby libUrl always 
attempts to GET 301 and 302 redirects whatever the original request 
method, but doesn't handle other responses.

In 1.1.1b1 only

-- Adds a new command libUrlSetSSLVerification <true|false>. (default 
is true)

   When set to true, libUrl will use the "with verification" form of the 
"open secure socket" command which uses certificates set in the 
SSLCertificates property. When set to false, the "without verification" 
form is used which enables encryted data transfer but without being 
certain who you're sending to or receiving from. Once set, the property 
is in use for all subsequent requests until it is set diffrently, so BE 
CAREFUL with this. (i.e. don't use it unless you know what you're 
doing)

Cheers
Dave