Search Results

Search found 78 results on 4 pages for 'damien roche'.

Page 4/4 | < Previous Page | 1 2 3 4 

  • Non-Dom Element Event Binding with jQuery

    - by Rick Strahl
    Yesterday I had a short discussion with Dave Reed on Twitter regarding setting up fake ‘events’ on objects that are hookable. jQuery makes it real easy to bind events on DOM elements and with a little bit of extra work (that I didn’t know about) you can also set up binding to non-DOM element ‘event’ bindings. Assume for a second that you have a simple JavaScript object like this: var item = { sku: "wwhelp" , foo: function() { alert('orginal foo function'); } }; and you want to be notified when the foo function is called. You can use jQuery to bind the handler like this: $(item).bind("foo", function () { alert('foo Hook called'); } ); Binding alone won’t actually cause the handler to be triggered so when you call: item.foo(); you only get the ‘original’ message. In order to fire both the original handler and the bound event hook you have to use the .trigger() function: $(item).trigger("foo"); Now if you do the following complete sequence: var item = { sku: "wwhelp" , foo: function() { alert('orginal foo function'); } }; $(item).bind("foo", function () { alert('foo hook called'); } ); $(item).trigger("foo"); You’ll see the ‘hook’ message first followed by the ‘original’ message fired in succession. In other words, using this mechanism you can hook standard object functions and chain events to them in a way similar to the way you can do with DOM elements. The main difference is that the ‘event’ has to be explicitly triggered in order for this to happen rather than just calling the method directly. .trigger() relies on some internal logic that checks for event bindings on the object (attached via an expando property) which .trigger() searches for in its bound event list. Once the ‘event’ is found it’s called prior to execution of the original function. This is pretty useful as it allows you to create standard JavaScript objects that can act as event handlers and are effectively hookable without having to explicitly override event definitions with JavaScript function handlers. You get all the benefits of jQuery’s event methods including the ability to hook up multiple events to the same handler function and the ability to uniquely identify each specific event instance with post fix string names (ie. .bind("MyEvent.MyName") and .unbind("MyEvent.MyName") to bind MyEvent). Watch out for an .unbind() Bug Note that there appears to be a bug with .unbind() in jQuery that doesn’t reliably unbind an event and results in a elem.removeEventListener is not a function error. The following code demonstrates: var item = { sku: "wwhelp", foo: function () { alert('orginal foo function'); } }; $(item).bind("foo.first", function () { alert('foo hook called'); }); $(item).bind("foo.second", function () { alert('foo hook2 called'); }); $(item).trigger("foo"); setTimeout(function () { $(item).unbind("foo"); // $(item).unbind("foo.first"); // $(item).unbind("foo.second"); $(item).trigger("foo"); }, 3000); The setTimeout call delays the unbinding and is supposed to remove the event binding on the foo function. It fails both with the foo only value (both if assigned only as “foo” or “foo.first/second” as well as when removing both of the postfixed event handlers explicitly. Oddly the following that removes only one of the two handlers works: setTimeout(function () { //$(item).unbind("foo"); $(item).unbind("foo.first"); // $(item).unbind("foo.second"); $(item).trigger("foo"); }, 3000); this actually works which is weird as the code in unbind tries to unbind using a DOM method that doesn’t exist. <shrug> A partial workaround for unbinding all ‘foo’ events is the following: setTimeout(function () { $.event.special.foo = { teardown: function () { alert('teardown'); return true; } }; $(item).unbind("foo"); $(item).trigger("foo"); }, 3000); which is a bit cryptic to say the least but it seems to work more reliably. I can’t take credit for any of this – thanks to Dave Reed and Damien Edwards who pointed out some of these behaviors. I didn’t find any good descriptions of the process so thought it’d be good to write it down here. Hope some of you find this helpful.© Rick Strahl, West Wind Technologies, 2005-2010Posted in jQuery  

    Read the article

  • Set-Cookie Headers getting stripped in ASP.NET HttpHandlers

    - by Rick Strahl
    Yikes, I ran into a real bummer of an edge case yesterday in one of my older low level handler implementations (for West Wind Web Connection in this case). Basically this handler is a connector for a backend Web framework that creates self contained HTTP output. An ASP.NET Handler captures the full output, and then shoves the result down the ASP.NET Response object pipeline writing out the content into the Response.OutputStream and seperately sending the HttpHeaders in the Response.Headers collection. The headers turned out to be the problem and specifically Http Cookies, which for some reason ended up getting stripped out in some scenarios. My handler works like this: Basically the HTTP response from the backend app would return a full set of HTTP headers plus the content. The ASP.NET handler would read the headers one at a time and then dump them out via Response.AppendHeader(). But I found that in some situations Set-Cookie headers sent along were simply stripped inside of the Http Handler. After a bunch of back and forth with some folks from Microsoft (thanks Damien and Levi!) I managed to pin this down to a very narrow edge scenario. It's easiest to demonstrate the problem with a simple example HttpHandler implementation. The following simulates the very much simplified output generation process that fails in my handler. Specifically I have a couple of headers including a Set-Cookie header and some output that gets written into the Response object.using System.Web; namespace wwThreads { public class Handler : IHttpHandler { /* NOTE: * * Run as a web.config set handler (see entry below) * * Best way is to look at the HTTP Headers in Fiddler * or Chrome/FireBug/IE tools and look for the * WWHTREADSID cookie in the outgoing Response headers * ( If the cookie is not there you see the problem! ) */ public void ProcessRequest(HttpContext context) { HttpRequest request = context.Request; HttpResponse response = context.Response; // If ClearHeaders is used Set-Cookie header gets removed! // if commented header is sent... response.ClearHeaders(); response.ClearContent(); // Demonstrate that other headers make it response.AppendHeader("RequestId", "asdasdasd"); // This cookie gets removed when ClearHeaders above is called // When ClearHEaders is omitted above the cookie renders response.AppendHeader("Set-Cookie", "WWTHREADSID=ThisIsThEValue; path=/"); // *** This always works, even when explicit // Set-Cookie above fails and ClearHeaders is called //response.Cookies.Add(new HttpCookie("WWTHREADSID", "ThisIsTheValue")); response.Write(@"Output was created.<hr/> Check output with Fiddler or HTTP Proxy to see whether cookie was sent."); } public bool IsReusable { get { return false; } } } } In order to see the problem behavior this code has to be inside of an HttpHandler, and specifically in a handler defined in web.config with: <add name=".ck_handler" path="handler.ck" verb="*" type="wwThreads.Handler" preCondition="integratedMode" /> Note: Oddly enough this problem manifests only when configured through web.config, not in an ASHX handler, nor if you paste that same code into an ASPX page or MVC controller. What's the problem exactly? The code above simulates the more complex code in my live handler that picks up the HTTP response from the backend application and then peels out the headers and sends them one at a time via Response.AppendHeader. One of the headers in my app can be one or more Set-Cookie. I found that the Set-Cookie headers were not making it into the Response headers output. Here's the Chrome Http Inspector trace: Notice, no Set-Cookie header in the Response headers! Now, running the very same request after removing the call to Response.ClearHeaders() command, the cookie header shows up just fine: As you might expect it took a while to track this down. At first I thought my backend was not sending the headers but after closer checks I found that indeed the headers were set in the backend HTTP response, and they were indeed getting set via Response.AppendHeader() in the handler code. Yet, no cookie in the output. In the simulated example the problem is this line:response.AppendHeader("Set-Cookie", "WWTHREADSID=ThisIsThEValue; path=/"); which in my live code is more dynamic ( ie. AppendHeader(token[0],token[1[]) )as it parses through the headers. Bizzaro Land: Response.ClearHeaders() causes Cookie to get stripped Now, here is where it really gets bizarre: The problem occurs only if: Response.ClearHeaders() was called before headers are added It only occurs in Http Handlers declared in web.config Clearly this is an edge of an edge case but of course - knowing my relationship with Mr. Murphy - I ended up running smack into this problem. So in the code above if you remove the call to ClearHeaders(), the cookie gets set!  Add it back in and the cookie is not there. If I run the above code in an ASHX handler it works. If I paste the same code (with a Response.End()) into an ASPX page, or MVC controller it all works. Only in the HttpHandler configured through Web.config does it fail! Cue the Twilight Zone Music. Workarounds As is often the case the fix for this once you know the problem is not too difficult. The difficulty lies in tracking inconsistencies like this down. Luckily there are a few simple workarounds for the Cookie issue. Don't use AppendHeader for Cookies The easiest and obvious solution to this problem is simply not use Response.AppendHeader() to set Cookies. Duh! Under normal circumstances in application level code there's rarely a reason to write out a cookie like this:response.AppendHeader("Set-Cookie", "WWTHREADSID=ThisIsThEValue; path=/"); but rather create the cookie using the Response.Cookies collection:response.Cookies.Add(new HttpCookie("WWTHREADSID", "ThisIsTheValue")); Unfortunately, in my case where I dynamically read headers from the original output and then dynamically  write header key value pairs back  programmatically into the Response.Headers collection, I actually don't look at each header specifically so in my case the cookie is just another header. My first thought was to simply trap for the Set-Cookie header and then parse out the cookie and create a Cookie object instead. But given that cookies can have a lot of different options this is not exactly trivial, plus I don't really want to fuck around with cookie values which can be notoriously brittle. Don't use Response.ClearHeaders() The real mystery in all this is why calling Response.ClearHeaders() prevents a cookie value later written with Response.AppendHeader() to fail. I fired up Reflector and took a quick look at System.Web and HttpResponse.ClearHeaders. There's all sorts of resetting going on but nothing that seems to indicate that headers should be removed later on in the request. The code in ClearHeaders() does access the HttpWorkerRequest, which is the low level interface directly into IIS, and so I suspect it's actually IIS that's stripping the headers and not ASP.NET, but it's hard to know. Somebody from Microsoft and the IIS team would have to comment on that. In my application it's probably safe to simply skip ClearHeaders() in my handler. The ClearHeaders/ClearContent was mainly for safety but after reviewing my code there really should never be a reason that headers would be set prior to this method firing. However, if for whatever reason headers do need to be cleared, it's easy enough to manually clear the headers out:private void RemoveHeaders(HttpResponse response) { List<string> headers = new List<string>(); foreach (string header in response.Headers) { headers.Add(header); } foreach (string header in headers) { response.Headers.Remove(header); } response.Cookies.Clear(); } Now I can replace the call the Response.ClearHeaders() and I don't get the funky side-effects from Response.ClearHeaders(). Summary I realize this is a total edge case as this occurs only in HttpHandlers that are manually configured. It looks like you'll never run into this in any of the higher level ASP.NET frameworks or even in ASHX handlers - only web.config defined handlers - which is really, really odd. After all those frameworks use the same underlying ASP.NET architecture. Hopefully somebody from Microsoft has an idea what crazy dependency was triggered here to make this fail. IAC, there are workarounds to this should you run into it, although I bet when you do run into it, it'll likely take a bit of time to find the problem or even this post in a search because it's not easily to correlate the problem to the solution. It's quite possible that more than cookies are affected by this behavior. Searching for a solution I read a few other accounts where headers like Referer were mysteriously disappearing, and it's possible that something similar is happening in those cases. Again, extreme edge case, but I'm writing this up here as documentation for myself and possibly some others that might have run into this. © Rick Strahl, West Wind Technologies, 2005-2012Posted in ASP.NET   IIS7   Tweet !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs"); (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/plusone.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();

    Read the article

  • How to get httrack to work with SSL on mac os x? (libssl.so not found)

    - by cwd
    I'm trying to use httrack website copier but the program is running and reporting "no-ssl" (ie: it does not have the capability to copy secure sites). From looking over this thread, it seems that the problem is either when I make & configure the program, or when I run the program, it is not finding the lib-ssl / open-ssl that I have installed. I think it is looking for /var/root/lib/libssl.so.1.0 The user on that forum states that he created a symlink which allowed httrack to find the ssl library in the non-default location. Perhaps that's what I need to do - but where do I create the link from and to? I'm not seeing that I have any libssl.so files installed on my system. Do I need the development package? If so, how do I install that? I used macports to install the current version of openssl that I have. I'm running OS X 10.6. Reserch I have run this command to try and debug: dtruss httrack 2&1 | grep ssl and that outputs this: stat64("libssl.so.1.0\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.1.0\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.1.0\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.1.0\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.1\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.1\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.1\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.1\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.1.0.0\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.1.0.0\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.1.0.0\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.1.0.0\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8p\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8p\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8p\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8p\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8o\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8o\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8o\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8o\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8n\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8n\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8n\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8n\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8m\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8m\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8m\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8m\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8l\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8l\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8l\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8l\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8k\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8k\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8k\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8k\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8j\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8j\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8j\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8j\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8g\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8g\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8g\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8g\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8b\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8b\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8b\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8b\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.8\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.8\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.8\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.8\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.7\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.7\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.7\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.7\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so.0.9.6\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so.0.9.6\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so.0.9.6\0", 0x7FFF5FBFF210, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so.0.9.6\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("libssl.so\0", 0x7FFF5FBFEE30, 0x7FFF5FBFF470) = -1 Err#2 stat64("/var/root/lib/libssl.so\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/local/lib/libssl.so\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 stat64("/usr/lib/libssl.so\0", 0x7FFF5FBFF220, 0x7FFF5FBFF470) = -1 Err#2 I have already used mac ports to install open-ssl: port installed The following ports are currently installed: beecrypt @4.2.1_2 (active) cpio @2.10_0 (active) expat @2.0.1_1 (active) flex @2.5.35_0 (active) gettext @0.18.1.1_2 (active) gperf @3.0.4_0 (active) icu @4.6_0 (active) libiconv @1.13.1_0 (active) mysql5 @5.1.53_0 (active) ncurses @5.9_0 (active) ncursesw @5.8_0 (active) neon @0.29.5_0 (active) openssl @1.0.0c_0 (active) perl5.8 @5.8.9_3 (active) popt @1.16_0 (active) python24 @2.4.6_7 (active) readline @6.1.002_0 (active) rpm @4.4.9_10 (active) sqlite3 @3.7.3_0 (active) zlib @1.2.5_0 (active) Here are the install locations: locate libssl /opt/local/lib/libssl.1.0.0.dylib /opt/local/lib/libssl.a /opt/local/lib/libssl.dylib /opt/local/lib/pkgconfig/libssl.pc /opt/local/var/macports/software/openssl/1.0.0c_0/opt/local/lib/libssl.1.0.0.dylib /opt/local/var/macports/software/openssl/1.0.0c_0/opt/local/lib/libssl.a /opt/local/var/macports/software/openssl/1.0.0c_0/opt/local/lib/libssl.dylib /opt/local/var/macports/software/openssl/1.0.0c_0/opt/local/lib/pkgconfig/libssl.pc /usr/lib/libssl.0.9.7.dylib /usr/lib/libssl.0.9.8.dylib /usr/lib/libssl.0.9.dylib /usr/lib/libssl.dylib /usr/lib/pkgconfig/libssl.pc What should I do next? More Info I tried the solution below: $ DYLD_INSERT_LIBRARIES="/opt/local/lib/libssl.1.0.0.dylib" httrack Welcome to HTTrack Website Copier (Offline Browser) 3.44-1-nossl Copyright (C) Xavier Roche and other contributors To see the option list, enter a blank line or try httrack --help It is still not able to load the ssl lib: 3.44-1-nossl

    Read the article

< Previous Page | 1 2 3 4