Re: NSURLRequest returning bizarre page
On Jun 10, 2013, at 5:32 PM, Trygve Inda wrote: > http://www.celestrak.com/NORAD/elements/stations.txt The JavaScript redirect you showed earlier appears to be that server's broken attempt to display a "page not found" error. Note the Content-Location header with "404" in it. Perhaps the file you want is temporarily absent from the server sometimes, when the data is updated or something. % curl -i http://www.celestrak.com/NORAD/elements/this-is-a-fake-file-name.txt HTTP/1.1 200 OK Content-Length: 481 Content-Type: text/html Content-Location: http://www.celestrak.com/redirect.htm?404;http://www.celestrak.com:80/NORAD/elements/this-is-a-fake-file-name.txt Last-Modified: Fri, 10 Sep 2004 21:40:52 GMT Accept-Ranges: bytes ETag: "d4cf1fd87e97c41:257" Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Date: Tue, 11 Jun 2013 19:01:40 GMT http://www.w3.org/TR/html4/loose.dtd";> Untitled Document var loc = escape(document.location.href); //var ref = escape(document.referrer); var newLoc = "/redirect.asp?loc=" + loc; window.location.href(newLoc); -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest returning bizarre page
Hello, [this message updated; previous message failed to get posted to the list] I noticed that the garbling is always "^M\n" -- indicating to me there is a newline/linebreak encoding issue. (especially since the server is a Microsoft monster). 2 ideas in order of likelihood: === (1) === Try setting the NSURLRequest to request *only* "text/plain", (Noticing how safari gets back "text/plain" mime type, but your cocoa app got back a (garbled) HTML. The result you got looks like untested code in the server for wrapping plain text into html format. I did some experimenting... Try this to check : // for testing use a header echo service ... NSURL* tleAddress = [NSURL URLWithString:@"http://scooterlabs.com/ echo.xml"]; // Must use NSMutableURLRequest .. .see http://stackoverflow.com/questions/4809047/nsurlrequest-setting-the- http-header NSMutableURLRequest* tleRequest = [[[NSMutableURLRequest alloc] initWithURL:tleAddress] autorelease]; [tleRequest setValue:@"text/plain" forHTTPHeaderField:@"Accept"]; // no trailing colon (:) NSURLResponse* tleResponse = nil; NSError* tleError = nil; NSData* tleData = [NSURLConnection sendSynchronousRequest:tleRequest returningResponse:&tleResponse error:&tleError]; NSString* tleString = [[[NSString alloc] initWithData:tleData encoding:NSUTF8StringEncoding] autorelease]; // for testing... NSLog(tleString); // look for the value inside the tags === (2) === try changing your NSUTF8StringEncoding to NSASCIIStringEncoding like so... NSString* tleString = [[[NSString alloc] initWithData:tleData encoding: NSASCIIStringEncoding] autorelease]; -- Manoah Adams On Jun 10, 2013, at 17:06 , Trygve Inda wrote: I am using the following code (url changed, but it is a .txt file) NSString* tleAddress = @"http://www.somesite.com/somefile.txt";; NSURLRequest* tleRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:tleAddress] cachePolicy:0 timeoutInterval:5.0]; NSURLResponse* tleResponse = nil; NSError* tleError = nil; NSData* tleData = [NSURLConnection sendSynchronousRequest:tleRequest returningResponse:&tleResponse error:&tleError]; NSString* tleString = [[[NSString alloc] initWithData:tleData encoding:NSUTF8StringEncoding] autorelease]; This works fine on my test systems and the vast majority of my customer's systems. I am able to open the URL in Safari and see that it is a raw text file. tleString comes back with the correct text. However, on some customer's systems, despite NSError not showing anything wrong, I get: ^M\nTransitional//EN"^M\n"http://www.w3.org/TR/html4/loose.dtd";>^M \n^M\n ead>^M\n^M\nUntitled Document^M\nlanguage="javascript">^M\nvar loc = escape (document.location.href);^M\n//var ref = escape(document.referrer);^M\nvar newLoc = "/redirect.asp?loc=" + loc;^M\nwindow.location.href(newLoc);^M\n^M\n^M\n^M \n^M\n y>^M\n^M I have no idea where this is coming from as it is certainly not in the file. The customer is not using a proxy or firewall and it happens in two different locations (so it could be related to the machine rather than the internet). Ideas? Thanks, Trygve ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/mhfadams% 40federaladamsfamily.com This email sent to mhfad...@federaladamsfamily.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest returning bizarre page
On Jun 10, 2013, at 5:06 PM, Trygve Inda wrote: > However, on some customer's systems, despite NSError not showing anything > wrong, I get: That’s a web page with a pretty clumsy way of redirecting to `/redirect.asp?loc=` followed by the actual URL. I have no idea why someone would do this instead of just configuring their web server to do the redirect (it takes like two lines in an Apache .htaccess file to do this.) > I have no idea where this is coming from as it is certainly not in the file. > The customer is not using a proxy or firewall and it happens in two > different locations (so it could be related to the machine rather than the > internet). I’d suspect the network the machine is on (maybe its router) having some kind of man-in-the-middle thing that’s trying to hijack the request somewhere else which can then send you to where you originally wanted to go. As though it were trying to get you to log in or accept terms&conditions or something. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest returning bizarre page
> Well, that's it, isn't it? > > > On Jun 10, 2013, at 8:32 PM, Trygve Inda wrote: > >>> What is the header of the file being fetched set to? >>> >>> On Jun 10, 2013, at 8:06 PM, Trygve Inda wrote: >> >> I believe it is just a plain text file. Safari will not allow me to view >> source on the page and FireFox says: >> >> text/plain >> ISO-8859-1 The document does not contain characters from outside ASCII range. It is just simple plain text. Containing the following: ISS (ZARYA) 1 25544U 98067A 13161.94249270 .6594 0-0 12012-3 0 9778 2 25544 51.6463 139.3070 0010655 55.8152 54.6961 15.50750172833731 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest returning bizarre page
Well, that's it, isn't it? On Jun 10, 2013, at 8:32 PM, Trygve Inda wrote: >> What is the header of the file being fetched set to? >> >> On Jun 10, 2013, at 8:06 PM, Trygve Inda wrote: > > I believe it is just a plain text file. Safari will not allow me to view > source on the page and FireFox says: > > text/plain > ISO-8859-1 > > FireFox also says: > > The character encoding of the plain text document was not declared. The > document will render with garbled text in some browser configurations if the > document contains characters from outside the US-ASCII range. The character > encoding of the file needs to be declared in the transfer protocol or file > needs to use a byte order mark as an encoding signature. @ > http://www.celestrak.com/NORAD/elements/stations.txt > > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest returning bizarre page
> What is the header of the file being fetched set to? > > On Jun 10, 2013, at 8:06 PM, Trygve Inda wrote: I believe it is just a plain text file. Safari will not allow me to view source on the page and FireFox says: text/plain ISO-8859-1 FireFox also says: The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature. @ http://www.celestrak.com/NORAD/elements/stations.txt ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest returning bizarre page
What is the header of the file being fetched set to? On Jun 10, 2013, at 8:06 PM, Trygve Inda wrote: > I am using the following code (url changed, but it is a .txt file) > > NSString* tleAddress = @"http://www.somesite.com/somefile.txt";; > > NSURLRequest* tleRequest = [NSURLRequest requestWithURL:[NSURL > URLWithString:tleAddress] cachePolicy:0 timeoutInterval:5.0]; > > NSURLResponse* tleResponse = nil; > > NSError* tleError = nil; > > NSData* tleData = [NSURLConnection sendSynchronousRequest:tleRequest > returningResponse:&tleResponse error:&tleError]; > > NSString* tleString = [[[NSString alloc] initWithData:tleData > encoding:NSUTF8StringEncoding] autorelease]; > > > This works fine on my test systems and the vast majority of my customer's > systems. I am able to open the URL in Safari and see that it is a raw text > file. > > tleString comes back with the correct text. > > However, on some customer's systems, despite NSError not showing anything > wrong, I get: > > ^M\n Transitional//EN"^M\n"http://www.w3.org/TR/html4/loose.dtd";>^M\n^M\n ead>^M\n^M\nUntitled Document^M\n language="javascript">^M\nvar loc = escape(document.location.href);^M\n > //var ref = escape(document.referrer);^M\nvar newLoc = > "/redirect.asp?loc=" + loc;^M\n > window.location.href(newLoc);^M\n^M\n^M\n^M\n^M\n y>^M\n^M > > I have no idea where this is coming from as it is certainly not in the file. > The customer is not using a proxy or firewall and it happens in two > different locations (so it could be related to the machine rather than the > internet). > > Ideas? > > Thanks, > > Trygve > > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest timing
On 2011 Sep 14, at 10:21, lcerveau wrote: > - At the same time I use a software like HTTPScoop to look on how it is > timing all this. Time are always différent like 0.05 seconds. I'm not familiar with HTTPScoop, but 50 milliseconds is typical for a single ping on the internet. > > So nearly always a factor of like 10. This is possible when multiple redirects, SSL handshaking, etc. become involved. I think that -connection:didReceiveResponse: which you are logging does not get invoked until all this is done. Log times in -connection:willSendRequest:redirectResponse: and you might see more. Also, for answers from people who are smarter than me on this topic, re-post to macnetworkp...@lists.apple.com. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest and NSOperationQueue
On 18 Jan 2010, at 16:37, Clint Shryock wrote: > I had the same issue in the past using NSOperationQueue and NSURLConnection, > and I resolved it by simply telling NSURLConnection to send using > synchronously using sendSynchronousRequest:returningResponse:error: > > Would that not take care of the issue? That is no different to servicing the run loop for an 'asynchronous' operation and is generally a bad idea in the worker threads; it needlessly removes them from the worker pool until the response has arrived. Please see my previous post for alternatives. Keith ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest and NSOperationQueue
I had the same issue in the past using NSOperationQueue and NSURLConnection, and I resolved it by simply telling NSURLConnection to send using synchronously using sendSynchronousRequest:returningResponse:error: Would that not take care of the issue? +Clint On Sun, Jan 17, 2010 at 1:55 PM, J. Scott Tury wrote: > The issue that Dave has run into is that when you call the asynchronous > NSURLConnection call, NSURLConnection looks to see what thread you are > calling it on, and it will only call your delegate back on that Thread (if > it exists). If you exit your NSOperation main method, your thread is going > to be cleaned up, and you will never get the delegate callbacks you want. > > Re-reading Dave's original email, I think what's probably happening to him > is that he may be switching the runLoops of ht eNSURLConnection BEFORE it > has actually started. Here's the comment from the documentation: > > You may call these methods after the connection has started. However, if > the connection is scheduled on multiple threads or if you are not calling > these methods from the thread where the connection is scheduled, there is a > race between these methods and the delivery of delegate methods on the other > threads. The caller must either be prepared for additional delegation > messages on the other threads, or must halt the run loops on the other > threads before calling these methods to guarantee that no further callbacks > will occur. > > Scott > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/cts3e1%40gmail.com > > This email sent to cts...@gmail.com > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest and NSOperationQueue
The issue that Dave has run into is that when you call the asynchronous NSURLConnection call, NSURLConnection looks to see what thread you are calling it on, and it will only call your delegate back on that Thread (if it exists). If you exit your NSOperation main method, your thread is going to be cleaned up, and you will never get the delegate callbacks you want. Re-reading Dave's original email, I think what's probably happening to him is that he may be switching the runLoops of ht eNSURLConnection BEFORE it has actually started. Here's the comment from the documentation: You may call these methods after the connection has started. However, if the connection is scheduled on multiple threads or if you are not calling these methods from the thread where the connection is scheduled, there is a race between these methods and the delivery of delegate methods on the other threads. The caller must either be prepared for additional delegation messages on the other threads, or must halt the run loops on the other threads before calling these methods to guarantee that no further callbacks will occur. Scott ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest and NSOperationQueue
Thanks for the responses! It hadn't occurred to me to spin the runloop myself. My main reason for using an NSOperationQueue for the connections was because the spawner of the connections was also the connection delegate, and it would've taken some interesting code dancing to handle the delegate callbacks of all the possible connections, the model objects they're attempting to create, etc in the same object. What I ended up doing was creating a new class, "DDURLConnectionDelegate", that is init'd with the object spawning the connections. This object exists solely to encapsulate the delegate callbacks of the NSURLConnection, and then, when finished, reports back to the connection spawner with the results, and is destroyed by the runloop. Now I can freely spawn as many connections as I need, all on the main thread, and have them all handled on a single thread, without having to worry about which connection is supposed to be manipulating which object. Cheers, Dave On Jan 17, 2010, at 9:20 AM, Keith Duncan wrote: >> Solution 1 would be to have you do a synchronous NSURLConnection in your >> main method. This will show you everything is working in that thread and >> that you do indeed get data back from your server. > > This isn't a good idea since it limits the cancelabilty of your operation. > >> NSRunLoop* currentRunLoop = [NSRunLoop currentRunLoop]; >> if ( currentRunLoop ) >> { >> // 1. Start the URLConnection! >> mURLConnection = [NSURLConnection connectionWithRequest:mURLRequest >> delegate:self]; >> [mURLConnection start]; >> >> // 2. We have a run Loop, so wait until the connection is finished >> while ( !done && ![self isCancelled] ) >> { >> // Run the RunLoop! >> NSDate* dateLimit = [[NSDate date] addTimeInterval:0.1]; >> [currentRunLoop runUntilDate:dateLimit]; >> } >> >> // 3. Report your results to your main thread! >> … >> } > > This is polling and is generally a bad idea, also with such a low timeout > your thread will thrash. Furthermore it ties the worker thread up until the > operation is complete. > > You should instead make a 'concurrent' NSOperation subclass as it's described > in NSOperation parlance. What it really means is an asynchronous one. > > Implement all the required 'concurrent operation' methods, and in -start you > do as you were doing, create an NSURLConnection and schedule it in the > +[NSRunLoop mainRunLoop]. In the completed callbacks (under error or success > conditions) you mark the operation as isFinished. > > This makes your operation cancellable, and frees the worker thread up to > service other work units. > > Keith > smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest and NSOperationQueue
> Solution 1 would be to have you do a synchronous NSURLConnection in your main > method. This will show you everything is working in that thread and that you > do indeed get data back from your server. This isn't a good idea since it limits the cancelabilty of your operation. > NSRunLoop* currentRunLoop = [NSRunLoop currentRunLoop]; > if ( currentRunLoop ) > { > // 1. Start the URLConnection! > mURLConnection = [NSURLConnection connectionWithRequest:mURLRequest > delegate:self]; > [mURLConnection start]; > > // 2. We have a run Loop, so wait until the connection is finished > while ( !done && ![self isCancelled] ) > { > // Run the RunLoop! > NSDate* dateLimit = [[NSDate date] addTimeInterval:0.1]; > [currentRunLoop runUntilDate:dateLimit]; > } > > // 3. Report your results to your main thread! > … > } This is polling and is generally a bad idea, also with such a low timeout your thread will thrash. Furthermore it ties the worker thread up until the operation is complete. You should instead make a 'concurrent' NSOperation subclass as it's described in NSOperation parlance. What it really means is an asynchronous one. Implement all the required 'concurrent operation' methods, and in -start you do as you were doing, create an NSURLConnection and schedule it in the +[NSRunLoop mainRunLoop]. In the completed callbacks (under error or success conditions) you mark the operation as isFinished. This makes your operation cancellable, and frees the worker thread up to service other work units. Keith ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest and NSOperationQueue
Dave, If you are setting up NSURLConnection on an NSOperation, I would suggest you keep the operation around as you get the data back. The symptom you describe, sounds like you are starting the NSURLConnection, but then you leave your main method in the NSOperation you created. This essentially orphans the thread that the NSURLConnection needs to report back progress to your delegate. If that Thread no longer exists, the NSURLConnection will never report back. Solution 1 would be to have you do a synchronous NSURLConnection in your main method. This will show you everything is working in that thread and that you do indeed get data back from your server. Solution 2 would be to change your NSOperation main method such that you start the NSURLConnection asynchronously, and you will need to loop until either you receive the connection:didFailWithError: delegate callback or you receive the connectionDidFinishLoading: delegate method callback. Since you're creating a NSOperation anyway, you probably want threaded access to your data. So I would work on solution #2. Your main method in your NSOperation subclass should be something simple like the following: NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; NSRunLoop* currentRunLoop = [NSRunLoop currentRunLoop]; if ( currentRunLoop ) { // 1. Start the URLConnection! mURLConnection = [NSURLConnection connectionWithRequest:mURLRequest delegate:self]; [mURLConnection start]; // 2. We have a run Loop, so wait until the connection is finished while ( !done && ![self isCancelled] ) { // Run the RunLoop! NSDate* dateLimit = [[NSDate date] addTimeInterval:0.1]; [currentRunLoop runUntilDate:dateLimit]; } // 3. Report your results to your main thread! ... } Scott Tury On Jan 17, 2010, at 12:08 AM, cocoa-dev-requ...@lists.apple.com wrote: > Subject: NSURLRequest and NSOperationQueue > > Hi everyone, > > I'm building an object that communicates with a server. For various reasons, > I'd like to queue up all the NSURLRequests in an NSOperationQueue so that I > never have more than one connection open at a time. > > However, I'm running into a weird issue. If I create my NSURLRequest and > open an NSURLConnection directly, then the connection works and everything > proceeds as expected. However, if I create an NSInvocationOperation to delay > the creation of the connection until the queue is idle, then the connection > is created (and is non-nil), but the URLRequest never triggers any of its > delegate methods. > > After some investigation, I realized that the operation was executing on a > different thread, so I scheduled the URLConnection on the mainRunLoop in the > default mode (after unscheduling from the currentRunLoop). I'm also > retaining the URLConnection in an ivar, but it's still not firing any > delegate methods (on any thread). > > Any ideas why my URL connection isn't working? > > Thanks, > > Dave DeLong ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest SSL Mac vs iPhone
On 16 Oct 2009, at 15:52, Greg Hoover wrote: It's signed by Verisign. Where does NSURLRequest and its supporting routines find the CA root certs? Are you sure it's the root certificate that it needs and not some certificate beneath that? Some CAs sign their SSL certs with certificates a few layers down from the actual root, and if you don't include the extra ones in the certificate chain **on your web server** then some machines would flag up an error while others (if they had some of these certificates installed locally) wouldn't. That seems to match the symptoms you're reporting, so it's worth checking out. Kind regards, Alastair -- http://alastairs-place.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest SSL Mac vs iPhone
On Oct 16, 2009, at 7:52 AM, Greg Hoover wrote: It's signed by Verisign. Where does NSURLRequest and its supporting routines find the CA root certs? In the Keychain. You can see the list of pre-installed root certs by launching Keychain Access and selecting "System Roots" from the keychain list. (It's also possible for other roots to be added to the system or login keychain, esp. if you're in a corporate environment.) I'm not sure if there's a way to find the root certs on iPhone. It would certainly have to be done programmatically, as there's no UI for viewing the keychain. The Keychain API on iPhone is entirely different than the one on Mac OS, and even more confusing. You should probably take this to the apple-cdsa list, which is actually for any security/crypto related issues. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest SSL Mac vs iPhone
On Oct 16, 2009, at 1:13 AM, Andrew Farmer wrote: On 16 Oct 2009, at 00:48, Greg Hoover wrote: I have the same piece of code making a secure request to a server in a Mac application and in an iPhone app. Both use an NSURLRequest with exactly the same settings, message, body, etc. On the Mac, the request succeeds, returning the data expected. On the iPhone however, the request fails with an "untrusted server certificate" error (NSURLErrorDomain -1202). My guess is the root certificates are different on the two platforms. Just a guess, but if the server you're connecting to is using a cert signed by a "weird" authority, that might be it. It's signed by Verisign. Where does NSURLRequest and its supporting routines find the CA root certs? I suspected that the iPhone implementation somehow doesn't have access to the root certificates, so I checked on the servers SSL cert using openssl. Openssl says: "unable to verify the first certificate". So now I figure that the Mac (10.6.1) implementation just allows the request to proceed when the verification fails (it doesn't return an error of any kind actually). Can anyone shed some light on this? OpenSSL is a red herring. NSURLRequest doesn't use openssl to verify certificates. In fact, openssl has no root certs installed at all by default on OS X, so it'll fail to verify any certificate at all. Well when I run OpenSSL on my own server it checks out fine. I was thinking that my CA root certs were just out of date, but when I run OpenSSL its more like it can't find several certs that should be part of the chain. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest SSL Mac vs iPhone
On 16 Oct 2009, at 00:48, Greg Hoover wrote: I have the same piece of code making a secure request to a server in a Mac application and in an iPhone app. Both use an NSURLRequest with exactly the same settings, message, body, etc. On the Mac, the request succeeds, returning the data expected. On the iPhone however, the request fails with an "untrusted server certificate" error (NSURLErrorDomain -1202). My guess is the root certificates are different on the two platforms. Just a guess, but if the server you're connecting to is using a cert signed by a "weird" authority, that might be it. I suspected that the iPhone implementation somehow doesn't have access to the root certificates, so I checked on the servers SSL cert using openssl. Openssl says: "unable to verify the first certificate". So now I figure that the Mac (10.6.1) implementation just allows the request to proceed when the verification fails (it doesn't return an error of any kind actually). Can anyone shed some light on this? OpenSSL is a red herring. NSURLRequest doesn't use openssl to verify certificates. In fact, openssl has no root certs installed at all by default on OS X, so it'll fail to verify any certificate at all. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest
On 10 Oct 2009, at 15:36, DKJ wrote: I've got an NSArray that I initialise with data from a plist stored on a remote webserver. I've been doing it like this: NSURL *url = [NSURL URLWithString:@"http://www.server.com/ data.plist"]; NSArray *myArray = [NSArray arrayWithContentsOfURL:url]; which has been working just fine so far. But now I'm reading through the "URL Loading System" docs, and wondering if I should be using all the NSURLRequest stuff instead. It's more complicated, so are there any advantages it would have over what I'm doing now? Advantages are: - Asynchronous operation so you don't block the runloop - More detailed error handling - Better authentication support - Finer control over the request, such as custom HTTP headers or timeout length ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest
On Oct 10, 2009, at 9:36 AM, DKJ wrote: I've got an NSArray that I initialise with data from a plist stored on a remote webserver. I've been doing it like this: NSURL *url = [NSURL URLWithString:@"http://www.server.com/ data.plist"]; NSArray *myArray = [NSArray arrayWithContentsOfURL:url]; which has been working just fine so far. But now I'm reading through the "URL Loading System" docs, and wondering if I should be using all the NSURLRequest stuff instead. It's more complicated, so are there any advantages it would have over what I'm doing now? arrayWithContentsOfURL: is a blocking call. Typically, when working with data over networks, it's best to do things asynchronously. When going the async route, you're going to get much better error- handling too. The call you're currently using will simply return nil upon any error. You then wouldn't know if the URL is bad, timeout occurred, file is bad, etc. ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest
On Oct 10, 2009, at 7:36 AM, DKJ wrote: I've got an NSArray that I initialise with data from a plist stored on a remote webserver. I've been doing it like this: NSURL *url = [NSURL URLWithString:@"http://www.server.com/ data.plist"]; NSArray *myArray = [NSArray arrayWithContentsOfURL:url]; which has been working just fine so far. But now I'm reading through the "URL Loading System" docs, and wondering if I should be using all the NSURLRequest stuff instead. It's more complicated, so are there any advantages it would have over what I'm doing now? if it's working well for you, why make things more complicated than necessary. ;-) NSURLRequest allows you to set and or get extra detail out of a URL, but for stuff like loading an array with a simple URL on a remote server, what you're doing should suffice. Just make sure myArray isn't null before you do any stuff on it. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest- setHTTPMethod to REPORT
On Fri, May 29, 2009 at 4:10 PM, Chris Purcell wrote: > Hello, > > I'm trying to issue a "REPORT" request to a server, the HTTP Method header > needs to look like this: > > REPORT /bernard/work/ HTTP/1.1 > > So I use setHTTPMethod to set the HTTP Method: [theRequest > setHTTPMethod:@"REPORT /bernard/work/"]; > > But when I issue the request, the server returns an error, because there is > an extra / in the request line: > > Bad request line: REPORT bernard/work/ / HTTP/1.1 > > > > Am I doing this the wrong way or is this not possible? > You are doing it wrong, but you are close. The method is only "REPORT", so you should just: [req setHTTPMethod:@"REPORT"] The "/bernard/work/" piece should be part of the NSURL you use to initialize your request. Jason ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSURLRequest conditional GET
below... On Jun 19, 2008, at 6:13 PM, Jens Alfke wrote: On 18 Jun '08, at 3:01 AM, Marc Monguio wrote: The documentation I've found about "Conditional GET" in the web says I should be sending "If-Modified-Since" and "If-None-Match" headers with the contents of "Last-Modified" and ETag" headers from the last server's answer. However it doesn't look like a NSURLRequest with a NSURLRequestUseProtocolCachePolicy is adding the "If-None-Match" header. Fortunately it adds the "Last-Modified" header automatically so I've tweaked my server-side to be able to work just with this header for caching. Is this a bug in NSURLRequestUseProtocolCachePolicy ? I think so; or at least a case where it's not being as optimal as it could be. I submitted a bug to Apple's. Id 6021187 When debugging the status in the "connection:didReceiveResponse:" delegate method the statusCode is always 200. I knew for sure than in fact it was being cached so I ran "tcpdump" and I saw that except the first call the rest were always Status Code 304 Not Modified. Why I can't see what I really get from the server in my code? I think the framework does this intentionally since it's hiding the details of the caching from you. Since you didn't explicitly add an if-modified-since header to your request, a 304 response wouldn't be a valid status code for the request as you generated it. I agree. My concern is that there seems to be no way to know if caching is actually working unless you sniff your TCP connections which is obviously a workaround. When I've implemented conditional requests, I've always added the necessary headers myself. I haven't used the CFNetwork cache at all in these cases; but I think you could do so by first sending the request in use-cache-only mode, checking the mod date and etag of the response, and then sending a request with your own if-none-match and if-modified-since headers, using the ignore-cache mode. Since my setup works I'll keep using NSURLRequest with NSURLRequestUseProtocolCachePolicy. It's always good to know that you have actually added the Headers manually and that it works. Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSURLRequest conditional GET
On 18 Jun '08, at 3:01 AM, Marc Monguio wrote: The documentation I've found about "Conditional GET" in the web says I should be sending "If-Modified-Since" and "If-None-Match" headers with the contents of "Last-Modified" and ETag" headers from the last server's answer. However it doesn't look like a NSURLRequest with a NSURLRequestUseProtocolCachePolicy is adding the "If-None-Match" header. Fortunately it adds the "Last-Modified" header automatically so I've tweaked my server-side to be able to work just with this header for caching. Is this a bug in NSURLRequestUseProtocolCachePolicy ? I think so; or at least a case where it's not being as optimal as it could be. When debugging the status in the "connection:didReceiveResponse:" delegate method the statusCode is always 200. I knew for sure than in fact it was being cached so I ran "tcpdump" and I saw that except the first call the rest were always Status Code 304 Not Modified. Why I can't see what I really get from the server in my code? I think the framework does this intentionally since it's hiding the details of the caching from you. Since you didn't explicitly add an if- modified-since header to your request, a 304 response wouldn't be a valid status code for the request as you generated it. When I've implemented conditional requests, I've always added the necessary headers myself. I haven't used the CFNetwork cache at all in these cases; but I think you could do so by first sending the request in use-cache-only mode, checking the mod date and etag of the response, and then sending a request with your own if-none-match and if-modified-since headers, using the ignore-cache mode. —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSURLRequest : Unable to Quit App after Syn call to Server.
// --- // 4) Convert Synchronous Data into Human-Readable String (Unicode 8) format: NSString *serverDataString = [[[NSString alloc] initWithData:serverData encoding:NSUTF8StringEncoding] retain]; This is an extra retain. [[soapResponse layoutManager]replaceTextStorage: [[NSTextStorage alloc] initWithString:serverDataString]]; you also leak the allocated NSTextStorage and in consquence every serverDataString ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSURLRequest : Unable to Quit App after Syn call to Server.
Thanks for the editing. Your help is deeply appreciated! Ric. On May 16, 2008, at 10:53 AM, stephen joseph butler wrote: Your code is crashing because you have numerous pointer and memory management issues. On Thu, May 15, 2008 at 4:21 PM, <[EMAIL PROTECTED]> wrote: - (IBAction)startSOAP:(id)sender { NSError **myError; NSError *myError; NSHTTPURLResponse **serverResponse; NSHTTPURLResponse *serverResponse; NSData *serverData; @try { // 1) The Request String. {not used yet} // Note: smsXMLString contains the entire SMS SOAP envelope, without the . NSString *smsXMLPath = [[NSBundle mainBundle] pathForResource:@"sms" ofType:@"xml"]; self.smsXMLString = [NSString stringWithContentsOfFile:smsXMLPath encoding:NSUTF8StringEncoding error:myError]; Use &myError // --- // 2) Create the request. NSURLRequest *theRequest=[NSURLRequest requestWithURL:[NSURL URLWithString:theServerURL] cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:10.0]; // --- // 3) Get Synchronous Data: serverData = [NSURLConnection sendSynchronousRequest:theRequest returningResponse:serverResponse error:myError]; Again, &myError and &serverResponse // --- // 4) Convert Synchronous Data into Human-Readable String (Unicode 8) format: NSString *serverDataString = [[[NSString alloc] initWithData:serverData encoding:NSUTF8StringEncoding] retain]; This is an extra retain. [[soapResponse layoutManager]replaceTextStorage: [[NSTextStorage alloc] initWithString:serverDataString]]; [serverDataString release]; } @catch (id e) { NSLog(@"\n {startSOAP} EXCEPTION: %@ \n",e); self.statusLine.stringValue = [NSString stringWithFormat:@"*** Exception flagged: %@ ***",e]; } @finally { NSLog(@"\n{startSoap} end."); } } // end startSOAP(). // --- - (IBAction)terminateSOAP:(id)sender { NSLog(@"\n{terminateSOAP} GoodBye.\n"); [NSApp stop:self];// < Does not work when above routine was performed. } ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSURLRequest : Unable to Quit App after Syn call to Server.
Your code is crashing because you have numerous pointer and memory management issues. On Thu, May 15, 2008 at 4:21 PM, <[EMAIL PROTECTED]> wrote: > - (IBAction)startSOAP:(id)sender { >NSError **myError; NSError *myError; >NSHTTPURLResponse **serverResponse; NSHTTPURLResponse *serverResponse; >NSData *serverData; > >@try { > >// 1) The Request String. {not used yet} >// Note: smsXMLString contains the entire SMS SOAP envelope, without > the . >NSString *smsXMLPath = [[NSBundle mainBundle] pathForResource:@"sms" > ofType:@"xml"]; >self.smsXMLString = [NSString stringWithContentsOfFile:smsXMLPath > encoding:NSUTF8StringEncoding error:myError]; Use &myError >// --- >// 2) Create the request. >NSURLRequest *theRequest=[NSURLRequest requestWithURL:[NSURL > URLWithString:theServerURL] > > cachePolicy:NSURLRequestUseProtocolCachePolicy > timeoutInterval:10.0]; > >// --- >// 3) Get Synchronous Data: >serverData = [NSURLConnection sendSynchronousRequest:theRequest > > returningResponse:serverResponse > > error:myError]; Again, &myError and &serverResponse >// --- >// 4) Convert Synchronous Data into Human-Readable String (Unicode 8) > format: >NSString *serverDataString = [[[NSString alloc] > initWithData:serverData encoding:NSUTF8StringEncoding] retain]; This is an extra retain. >[[soapResponse layoutManager]replaceTextStorage:[[NSTextStorage alloc] > initWithString:serverDataString]]; > >[serverDataString release]; > >} @catch (id e) { >NSLog(@"\n {startSOAP} EXCEPTION: %@ \n",e); >self.statusLine.stringValue = [NSString stringWithFormat:@"*** > Exception flagged: %@ ***",e]; >} @finally { > >NSLog(@"\n{startSoap} end."); >} > > > } // end startSOAP(). > > // --- > > - (IBAction)terminateSOAP:(id)sender { >NSLog(@"\n{terminateSOAP} GoodBye.\n"); >[NSApp stop:self];// < Does not work when above routine was > performed. > } ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSURLRequest : Unable to Quit App after Syn call to Server. SOLVED???
I needed to modify the default 'GET' Response of the NSURLRequest to a 'POST'... So I changed 'NSURLRequest' to a 'NSMutableURLRequest' to modify the HTTPMethod: // --- // 2) Create the request. NSMutableURLRequest *theRequest=[NSMutableURLRequest requestWithURL:[NSURL URLWithString:theServerURL] cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:10.0]; // --- // 2a) Modify the Request from default 'GET' to 'POST': [theRequest setHTTPMethod:@"POST"]; Now, I can QUIT (via [NSAPP Terminate:self] without residual errors, etc. I'm not sure why... ..but it "solved". Ric. On 05/16/2008 06:32 [EMAIL PROTECTED] wrote .. > On 05/15/2008 17:56 Jens Alfke wrote .. > > "...You should call [NSApp terminate: self] instead. " > > I did that; and repeated it. > > I'm running in debug mode. The program "works" till I QUIT via [NSApp > terminate:self]. > > Now I'm getting (via gdb console {Running as a Cocoa App on my MacBookPro): > > Running > 2008-05-16 09:18:52.868 iPhoneSOAP (Cocoa version)[553:817] > {AppDelegate} startSOAP start > 2008-05-16 09:18:53.079 iPhoneSOAP (Cocoa version)[553:817] > {startSoap} end. > Program received signal: EXC_BAD_ACCESS. > (gdb) > > Here's a piece of the Error Report: > .. > Date/Time: 2008-05-16 09:33:54.449 -0400 > OS Version: Mac OS X 10.5.2 (9C7010) > Report Version: 6 > > Exception Type: EXC_BAD_ACCESS (SIGBUS) > Exception Codes: KERN_PROTECTION_FAILURE at 0x0010 > Crashed Thread: 0 > .. > > I don't know why this is happening; of course I'm suspecting the SYNCHRONOUS > connection > to the server is the source... > > Does NSURLRequest need to be CLOSED before exit? > I don't remember seeing NSURLRequest closer in the doc. > > Any ideas/remedies for the EXC_BAD_ACCESS (SIGBUS)? > > Ric. > > > > On 05/15/2008 17:56 Jens Alfke wrote .. > > > > On 15 May '08, at 2:21 PM, [EMAIL PROTECTED] wrote: > > > > >The Cocoa code below "works". I get data back from the server. > > > However, I'm unable to QUIT this application after this particular > > > routine passes through. I checked the Activity Monitor and can see > > > a bunch of threads still in session: > > > > That's expected, and not a problem. CFNetwork uses a background thread > > to perform its I/O. > > > > >[NSApp stop:self];// < Does not work when above > > > routine was performed. > > > > That's your problem. You should call [NSApp terminate: self] instead. > > Although you shouldn't even need that the standard Quit menu command > > is already bound to that action. > > > > Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSURLRequest : Unable to Quit App after Syn call to Server.
On 05/15/2008 17:56 Jens Alfke wrote .. "...You should call [NSApp terminate: self] instead. " I did that; and repeated it. I'm running in debug mode. The program "works" till I QUIT via [NSApp terminate:self]. Now I'm getting (via gdb console {Running as a Cocoa App on my MacBookPro): Running 2008-05-16 09:18:52.868 iPhoneSOAP (Cocoa version)[553:817] {AppDelegate} startSOAP start 2008-05-16 09:18:53.079 iPhoneSOAP (Cocoa version)[553:817] {startSoap} end. Program received signal: EXC_BAD_ACCESS. (gdb) Here's a piece of the Error Report: .. Date/Time: 2008-05-16 09:33:54.449 -0400 OS Version: Mac OS X 10.5.2 (9C7010) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0010 Crashed Thread: 0 .. I don't know why this is happening; of course I'm suspecting the SYNCHRONOUS connection to the server is the source... Does NSURLRequest need to be CLOSED before exit? I don't remember seeing NSURLRequest closer in the doc. Any ideas/remedies for the EXC_BAD_ACCESS (SIGBUS)? Ric. On 05/15/2008 17:56 Jens Alfke wrote .. > > On 15 May '08, at 2:21 PM, [EMAIL PROTECTED] wrote: > > >The Cocoa code below "works". I get data back from the server. > > However, I'm unable to QUIT this application after this particular > > routine passes through. I checked the Activity Monitor and can see > > a bunch of threads still in session: > > That's expected, and not a problem. CFNetwork uses a background thread > to perform its I/O. > > >[NSApp stop:self];// < Does not work when above > > routine was performed. > > That's your problem. You should call [NSApp terminate: self] instead. > Although you shouldn't even need that the standard Quit menu command > is already bound to that action. > > Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSURLRequest : Unable to Quit App after Syn call to Server.
On 15 May '08, at 2:21 PM, [EMAIL PROTECTED] wrote: The Cocoa code below "works". I get data back from the server. However, I'm unable to QUIT this application after this particular routine passes through. I checked the Activity Monitor and can see a bunch of threads still in session: That's expected, and not a problem. CFNetwork uses a background thread to perform its I/O. [NSApp stop:self];// < Does not work when above routine was performed. That's your problem. You should call [NSApp terminate: self] instead. Although you shouldn't even need that — the standard Quit menu command is already bound to that action. —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]