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

_______________________________________________
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Reply via email to