Re: NSURLRequest returning bizarre page

2013-06-11 Thread Greg Parker
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

2013-06-11 Thread Manoah F. Adams

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\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/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]