Re: Lifecycle for custom NSURLProtocol properties

2016-09-27 Thread Jens Alfke

> On Sep 26, 2016, at 10:42 PM, Allan Odgaard  
> wrote:
> 
> I am making use of NSURLProtocol’s `setProperty:forKey:inRequest:` but it 
> seems that my custom properties outlive the URL request, and even if I 
> explicitly call `removePropertyForKey:inRequest:` after my request is done, 
> it would appear that my properties are still being retained by something.

Are they actually getting leaked? Does the memory usage of these values keep 
increasing over time?

> I guess this is a bit of a black box, but does anyone have any 
> info/experience with this?

I’d recommend asking on the macnetworkprog list; there are more folks there 
(including Quinn) who might now for sure.

—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

Lifecycle for custom NSURLProtocol properties

2016-09-26 Thread Allan Odgaard
I am making use of NSURLProtocol’s `setProperty:forKey:inRequest:` but 
it seems that my custom properties outlive the URL request, and even if 
I explicitly call `removePropertyForKey:inRequest:` after my request is 
done, it would appear that my properties are still being retained by 
something.


I guess this is a bit of a black box, but does anyone have any 
info/experience with this?

___

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: NSURLProtocol

2015-04-13 Thread Mike Abdullah
Yes, but it’s up to WebKit how it decides to handle the content of the page, 
and what it agrees to hand off to NSURLProtocol. Perhaps most importantly, the 
webkit list has more WebKit engineers monitoring it; you’re more likely to get 
a decent response.

> On 13 Apr 2015, at 18:37, danchik  wrote:
> 
> question has nothing to do with webkit, the NSURLProtocol is part of 
> foundation library, the fact that it is implemented inside a plugin, and can 
> also be instanciated inside a webview, does not make it a webkit question.
> 
>> On Apr 12, 2015, at 2:30 AM, Mike Abdullah  wrote:
>> 
>> 
>>> On 12 Apr 2015, at 04:07, danchik  wrote:
>>> 
>>> an npapi plugin on a web page, it registers a protocol handler
>> 
>> I’d say you’re on the wrong list then. This comes down almost entirely to 
>> what has been implemented/allowed for Safari, rather than being a general 
>> Cocoa question. Possibly the Webkitsdk-dev list is a better bet.
>> 


___

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: NSURLProtocol

2015-04-13 Thread danchik
question has nothing to do with webkit, the NSURLProtocol is part of foundation 
library, the fact that it is implemented inside a plugin, and can also be 
instanciated inside a webview, does not make it a webkit question.

> On Apr 12, 2015, at 2:30 AM, Mike Abdullah  wrote:
> 
> 
>> On 12 Apr 2015, at 04:07, danchik  wrote:
>> 
>> an npapi plugin on a web page, it registers a protocol handler
> 
> I’d say you’re on the wrong list then. This comes down almost entirely to 
> what has been implemented/allowed for Safari, rather than being a general 
> Cocoa question. Possibly the Webkitsdk-dev list is a better bet.
> 

___

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: NSURLProtocol

2015-04-12 Thread Mike Abdullah

> On 12 Apr 2015, at 04:07, danchik  wrote:
> 
> an npapi plugin on a web page, it registers a protocol handler 

I’d say you’re on the wrong list then. This comes down almost entirely to what 
has been implemented/allowed for Safari, rather than being a general Cocoa 
question. Possibly the Webkitsdk-dev list is a better bet.


___

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: NSURLProtocol

2015-04-11 Thread danchik
well, the simplest irl example I can think of why you would want an arbitrary 
protocol is this - imagine you have a plugin on you web page that can generate 
some custom images for user. Now you want to show those files in img tags (so 
some one else can nicely wrap them in html). How would you show the images, 
again generated on a customer's computer on their local drive and considering 
the web page is served from https://, where the standard file:// protocol will 
not work (and properly so) in any of the latest browsers when page is served 
from http(s)://

I don't see how intranet or internet matters for custom protocol, it's kind of 
one of the points of 'custom' protocol.  I was trying to figure out why the 
behavior was different between the versions of Safari - if it was something I 
needed to add to the protocol handler registration, or if it was some change in 
plugin encapsulation and I should use something other than NSURLProtocol?  or 
 

> On Apr 11, 2015, at 10:09 PM, David Grant  wrote:
> 
> Ok, so my personal knowledge stops at the point at which you create a new 
> protocol, with the exception of an intranet, and please forgive me for not 
> reading beyond that, because as far as I know in my experience and expertise 
> there is no reason or purpose, again beyond an intranet, that one would 
> possibly produce an xyz:// 
> 
> And if you can prove something beyond a hypothetical link to an https:// 
> while you’re conversion about an xyz:// I would sincerely encourage you to 
> enlighten me because I would always be the first to acknowledge I know 
> nothing.
> 
> I would suggest, if I could assist in any way, and please let me know if I am 
> not, but if I can, how do I venture forth to that site in a standard browser 
> without non-standard definitions I would most graciously be both enlightened 
> and willing to assist in any way possible.
> 
> 
> 
>> On Apr 11, 2015, at 9:29 PM, Dan S  wrote:
>> 
>> No, I mean I literally register a new protocol:   xyz://
>> 
>> There are no typos because it is defined as a @"xyz" in the a single place
>> in the header file, and all of the code refers to it by its define.
>> 
>> 
>> When you go to my page at https://example.com/mypluginpage.html (for
>> example) the Safari loads the page and creates my plugin (I know that
>> because I can step into it :)), at which point the plugin immediately
>> registered a new protocol 'xyz://' with NSURLProtocol, and result of
>> registration is always YES. But it works in Safari 5.1 but NOT in Safari
>> 5.1.10
>> 
>> Here are more details:
>> 
>> On that page there is a button, it makes the plugin do some work, render an
>> image (which I confirmed it successfully rendered and save into a file),
>> then jscript code inserts an image into a page (same page no navigation)
>> for example   At this point I expect
>> Safari to call method on my plugin:
>> +(BOOL) canInitWithRequest:(NSUrlRequest): -- to ask if I handle 'xyz://'
>> 
>> Now here is where behavior differs between Safari 5.1 and Safari 5.1.10:
>> 
>> When the page runs in Safari 5.1 (osx 10.5) I do get calls to it for every
>> image, script tag, style link ... basically for every link on the page,
>> asking if I handle 'https://' to which I say NO; now when it comes time for
>> drawing my image, it comes in the same to canInitWithRequest and asks if I
>> handle 'xyz://' then I say YES and the rest is as expected I get the rest
>> of the calls for canonicalization and processing the request.
>> 
>> Now if I change to the same exact machine (osx 10.5) except that it is
>> running Safari 5.1.10, I do the same thing, go to the web page with the
>> plugin, it is instantiated (I can step into it) and it registers the
>> protocol handler, and I do see all the calls coming in asking if I handle
>> 'https://' just like before, but It NEVER comes in for 'xyz://' when its
>> time to render my image.  I have confirmed that the src of the image is
>> correctly formatted (and NOT any different than on the machines that it
>> does work on), but still my protocol handler never gets asked about the
>> 'xyz' protocol (even though it returned YES when I did the register class
>> with NSURLProtocol), and Safari acts as if 'xyz:'' has never been
>> registered.
>> 
>> 
>> The same behavior is consistently reproduced on other OSX version (tried on
>> leopard and lion), the 5.1 Safari works and processes the 'xyz://'
>> protocol, but 5.1.10 does not.
>> 
>>> 
>>> 
>>>

Re: NSURLProtocol

2015-04-11 Thread Dan S
No, I mean I literally register a new protocol:   xyz://

There are no typos because it is defined as a @"xyz" in the a single place
in the header file, and all of the code refers to it by its define.


When you go to my page at https://example.com/mypluginpage.html (for
example) the Safari loads the page and creates my plugin (I know that
because I can step into it :)), at which point the plugin immediately
registered a new protocol 'xyz://' with NSURLProtocol, and result of
registration is always YES. But it works in Safari 5.1 but NOT in Safari
5.1.10

Here are more details:

On that page there is a button, it makes the plugin do some work, render an
image (which I confirmed it successfully rendered and save into a file),
then jscript code inserts an image into a page (same page no navigation)
for example   At this point I expect
Safari to call method on my plugin:
 +(BOOL) canInitWithRequest:(NSUrlRequest): -- to ask if I handle 'xyz://'

Now here is where behavior differs between Safari 5.1 and Safari 5.1.10:

When the page runs in Safari 5.1 (osx 10.5) I do get calls to it for every
image, script tag, style link ... basically for every link on the page,
asking if I handle 'https://' to which I say NO; now when it comes time for
drawing my image, it comes in the same to canInitWithRequest and asks if I
handle 'xyz://' then I say YES and the rest is as expected I get the rest
of the calls for canonicalization and processing the request.

Now if I change to the same exact machine (osx 10.5) except that it is
running Safari 5.1.10, I do the same thing, go to the web page with the
plugin, it is instantiated (I can step into it) and it registers the
protocol handler, and I do see all the calls coming in asking if I handle
'https://' just like before, but It NEVER comes in for 'xyz://' when its
time to render my image.  I have confirmed that the src of the image is
correctly formatted (and NOT any different than on the machines that it
does work on), but still my protocol handler never gets asked about the
'xyz' protocol (even though it returned YES when I did the register class
with NSURLProtocol), and Safari acts as if 'xyz:'' has never been
registered.


The same behavior is consistently reproduced on other OSX version (tried on
leopard and lion), the 5.1 Safari works and processes the 'xyz://'
protocol, but 5.1.10 does not.

>
>
> On Sat, Apr 11, 2015 at 8:57 PM, David Grant 
> wrote:
>
>> I’m assuming xyz:// = http://
>>
>> There must something in your config designated to only respond to https://
>> ?
>>
>> Either that or you have both http:// and https:// written in your code
>> at different points.
>>
>> So I suppose the first question to be asked is, do you INTEND to use http
>> or https?
>>
>>
>> On Apr 11, 2015, at 8:07 PM, danchik  wrote:
>>
>> an npapi plugin on a web page, it registers a protocol handler
>>
>> On Apr 11, 2015, at 2:26 AM, Mike Abdullah  wrote:
>>
>>
>> On 11 Apr 2015, at 02:28, Dan S  wrote:
>>
>> Is behavior of NSURLProtocol changed with Safari 5.1?
>>
>> I have a plugin that registeres a protocol handler xyz://  for example
>>
>>
>> Could clarify what exactly you mean by “plugin” here?
>>
>>
>> It succeeds and I can see all the requests to files on web pages being
>> consulted with the object via
>> +(BOOL) canInitWithRequest:(NSUrlRequest):
>>
>> With Safari 5.0 I would get consulted on all schemas (of cource it would
>> only return YES for the xyz://)  but with Safari 5.1.10 the only
>> consultation I get (canInitWithRequest) are with the webpage schema
>> (https://) and never see any calls asking about xyz:// protocol
>>
>>
>> What can I do to get it to work in Safari 5.1.10?
>>
>> On PC for example, when registering custom protocol I actually have to
>> specify that it is secure and ok to be invoked when running from HTTPS,  I
>> did not see anything like that on OSX, is that the problem and if so is
>> there a fix for it?
>>
>> Thank you
>> ___
>>
>> 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/mabdullah%40karelia.com
>>
>> This email sent to mabdul...@karelia.com
>>
>>
>>
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>

Re: NSURLProtocol

2015-04-11 Thread danchik
an npapi plugin on a web page, it registers a protocol handler 

> On Apr 11, 2015, at 2:26 AM, Mike Abdullah  wrote:
> 
> 
>> On 11 Apr 2015, at 02:28, Dan S  wrote:
>> 
>> Is behavior of NSURLProtocol changed with Safari 5.1?
>> 
>> I have a plugin that registeres a protocol handler xyz://  for example
> 
> Could clarify what exactly you mean by “plugin” here?
>> 
>> It succeeds and I can see all the requests to files on web pages being
>> consulted with the object via
>> +(BOOL) canInitWithRequest:(NSUrlRequest):
>> 
>> With Safari 5.0 I would get consulted on all schemas (of cource it would
>> only return YES for the xyz://)  but with Safari 5.1.10 the only
>> consultation I get (canInitWithRequest) are with the webpage schema
>> (https://) and never see any calls asking about xyz:// protocol
>> 
>> 
>> What can I do to get it to work in Safari 5.1.10?
>> 
>> On PC for example, when registering custom protocol I actually have to
>> specify that it is secure and ok to be invoked when running from HTTPS,  I
>> did not see anything like that on OSX, is that the problem and if so is
>> there a fix for it?
>> 
>> Thank you
>> ___
>> 
>> 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/mabdullah%40karelia.com
>> 
>> This email sent to mabdul...@karelia.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: NSURLProtocol

2015-04-11 Thread Mike Abdullah

> On 11 Apr 2015, at 02:28, Dan S  wrote:
> 
> Is behavior of NSURLProtocol changed with Safari 5.1?
> 
> I have a plugin that registeres a protocol handler xyz://  for example

Could clarify what exactly you mean by “plugin” here?
> 
> It succeeds and I can see all the requests to files on web pages being
> consulted with the object via
> +(BOOL) canInitWithRequest:(NSUrlRequest):
> 
> With Safari 5.0 I would get consulted on all schemas (of cource it would
> only return YES for the xyz://)  but with Safari 5.1.10 the only
> consultation I get (canInitWithRequest) are with the webpage schema
> (https://) and never see any calls asking about xyz:// protocol
> 
> 
> What can I do to get it to work in Safari 5.1.10?
> 
> On PC for example, when registering custom protocol I actually have to
> specify that it is secure and ok to be invoked when running from HTTPS,  I
> did not see anything like that on OSX, is that the problem and if so is
> there a fix for it?
> 
> Thank you
> ___
> 
> 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/mabdullah%40karelia.com
> 
> This email sent to mabdul...@karelia.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

NSURLProtocol

2015-04-10 Thread Dan S
Is behavior of NSURLProtocol changed with Safari 5.1?

I have a plugin that registeres a protocol handler xyz://  for example

It succeeds and I can see all the requests to files on web pages being
consulted with the object via
+(BOOL) canInitWithRequest:(NSUrlRequest):

With Safari 5.0 I would get consulted on all schemas (of cource it would
only return YES for the xyz://)  but with Safari 5.1.10 the only
consultation I get (canInitWithRequest) are with the webpage schema
(https://) and never see any calls asking about xyz:// protocol


What can I do to get it to work in Safari 5.1.10?

On PC for example, when registering custom protocol I actually have to
specify that it is secure and ok to be invoked when running from HTTPS,  I
did not see anything like that on OSX, is that the problem and if so is
there a fix for it?

Thank you
___

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

Can't get first try of NSURLProtocol subclass to work.

2014-10-20 Thread Daryle Walker
I entered a URL that triggers my handler, but I get this from the Xcode debug 
log:

> 2014-10-20 07:42:08.968 MyApp[94134:303] *** Assertion failure in -[NSWindow 
> setTitle:], /SourceCache/AppKit/AppKit-1265.21/AppKit.subproj/NSWindow.m:2901
> 2014-10-20 07:42:08.972 MyApp[94134:303] *** WebKit discarded an uncaught 
> exception in the webView:didFinishLoadForFrame: delegate: 
>  Invalid parameter not satisfying: aString 
> != nil


Here’s my -startLoading method. I tried “about:”, which is the only URL I 
handle directly in the method.

> - (void)startLoading {
> NSAssert([self.class canInitWithRequest:self.request], @"Inappropriate 
> request.");
> NSAssert(!self.processing, @"Receiving new protocol request while 
> processing another.");
> 
> // Handle the blank "about:" URL.
> NSString * const  path = self.request.URL.path;
> NSString * const  query = self.request.URL.query;
> 
> if (!path || [path isEqualToString:@""]) {
> if (query) goto error;
> NSStringEncoding const  encoding = NSUTF8StringEncoding;
> NSData * const aboutData = 
> [@"aboutabout:" 
> dataUsingEncoding:encoding];
> 
> [self.client URLProtocol:self didReceiveResponse:[[NSURLResponse 
> alloc] initWithURL:self.request.URL MIMEType:@"text/html" 
> expectedContentLength:aboutData.length 
> textEncodingName:nil/*(__bridge_transfer NSString 
> *)CFStringConvertEncodingToIANACharSetName(CFStringConvertNSStringEncodingToEncoding(encoding))*/]
>  cacheStoragePolicy:NSURLCacheStorageNotAllowed];
> [self.client URLProtocol:self didLoadData:aboutData];
> [self.client URLProtocolDidFinishLoading:self];
> } else {
> NSString * const  handler = AboutKeyToSelectorMap()[path];
> 
> if (handler) {
> self.processing = [NSThread currentThread];
> self.cancelled = NO;
> [self performSelector:NSSelectorFromString(handler) 
> withObject:query afterDelay:0.0 inModes:@[[NSRunLoop 
> currentRunLoop].currentMode, NSDefaultRunLoopMode]];
> } else {
> goto error;
> }
> }
> return;
> 
> error:
> // Bad response.
> [self.client URLProtocol:self didFailWithError:[NSError 
> errorWithDomain:NSURLErrorDomain code:NSURLErrorResourceUnavailable 
> userInfo:nil]];
> }


I thought using “nil” instead of the big expression calculating the encoding 
string would make a difference. It didn’t.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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: Why are properties access through NSURLProtocol class method rather than NSURLRequest instance method?

2011-05-16 Thread Mike Abdullah

On 16 May 2011, at 03:57, Larry Campbell wrote:

> Seems odd to me that setting and getting properties of an NSURLRequest 
> involve an NSURLProtocol class method:
> 
>+[NSURLProtocol setProperty:forKey:inRequest:]
> 
> rather than what seems to me the much more straightforward:
> 
>-[NSMutableURLRequest setProperty:forKey:]
> 
> Is there a reason for this?

This facility is provided for people creating custom URL protocols. I think 
it's assumed that if you need custom request properties, you'll write something 
like:

@implementation NSURLRequest (MyProtocol)
- (NSString *)myFoo;
{
  return [NSURLProtocol propertyForKey:@"myFoo" inRequest:self];
}
@end

@implementation NSMutableURLRequest (MyProtocol)
- (void)setMyFoo:(NSString *)foo
{
  if (foo)
  {
[NSURLProtocol setProperty:foo forKey:@"myFoo" inRequest:self];
  }
  else
  {
[NSURLProtocol removePropertyForKey:@"myFoo" inRequest:self];
  }
}

___

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


Why are properties access through NSURLProtocol class method rather than NSURLRequest instance method?

2011-05-15 Thread Larry Campbell
Seems odd to me that setting and getting properties of an NSURLRequest involve 
an NSURLProtocol class method:

+[NSURLProtocol setProperty:forKey:inRequest:]

rather than what seems to me the much more straightforward:

-[NSMutableURLRequest setProperty:forKey:]

Is there a reason for this?

- lc



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: WebView NSURLProtocol Tiger problems.

2010-11-04 Thread Mr. Gecko
In the start loading method, this is what I'm doing if it helps some. I found 
that I cannot do a web server with this as it doesn't forward the post data 
which is important in this application.

- (void)startLoading {
NSURLResponse *response = [[NSURLResponse alloc] initWithURL:[[self 
request] URL] MIMEType:@"text/html" expectedContentLength:0 
textEncodingName:nil];
NSMutableURLRequest *request = [[self request] mutableCopy];
NSString *url = [[request URL] absoluteString];
NSRange range = [url rangeOfString:@":"];
url = [@"https" stringByAppendingString:[url 
substringFromIndex:range.location]];
[request setURL:[NSURL URLWithString:url]];

id client = [self client];
[client URLProtocol:self wasRedirectedToRequest:request 
redirectResponse:response];
[client URLProtocolDidFinishLoading:self];

[request release];
[response release];
}

On Nov 4, 2010, at 10:55 AM, Mr. Gecko wrote:

> For some reason, on tiger, when you make your own protocol using 
> NSURLProtocol and respond with 
> URLProtocol:wasRedirectedToRequest:redirectResponse:redirectResponse to a 
> WebView, it just doesn't redirect at all. Is this a known bug? Do I have to 
> write a web server to redirect someone to somewhere on tiger?

___

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


WebView NSURLProtocol Tiger problems.

2010-11-04 Thread Mr. Gecko
For some reason, on tiger, when you make your own protocol using NSURLProtocol 
and respond with 
URLProtocol:wasRedirectedToRequest:redirectResponse:redirectResponse to a 
WebView, it just doesn't redirect at all. Is this a known bug? Do I have to 
write a web server to redirect someone to somewhere on 
tiger?___

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


Subclass NSURLProtocol, and file /Developer/Examples/WebKit/PictureBrowser/

2010-10-28 Thread Wayne Shao
Hi,

I tried to find an example of subclassing NSURLProtocol.
Some web forums points to  /Developer/Examples/WebKit/PictureBrowser/, which
is not on my system. How do I install that?
Or is there another similar example?

-- 
W. Shao
___

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: Custom NSURLProtocol crashes when using Garbage Collection

2009-10-20 Thread Keith Duncan
At this point I expect there's a GC bug in the NSURLProtocol  
machinery, specifically the bridge between NSURLProtocol and  
CFURLProtocol. We'll look further in 7314551.


Thanks for checking for me, I was holding out on hope that there was  
actually bug in my code so that I could still get it working.


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: Custom NSURLProtocol crashes when using Garbage Collection

2009-10-19 Thread Greg Parker

On Oct 19, 2009, at 2:16 AM, Keith Duncan wrote:
I wrote a simple NSURLProtocol subclass and started observing  
crashes in URL Loading code. I've extracted the crasher into a  
simple test project which loads an image from a URL with custom  
scheme which I handle every hundredth of a second.


When compiled with -fobjc-gc it reliably crashes; without it runs  
indefinitely however, there are leaked NSString instances allocated  
by NSURLConnection in +sendSynchronousRequest:… I've filed this as rdar://problem/7314551 
 for reference.


The test project can be found http://33software.com/files/CrashLoadingURL.zip 
 The bug is reproductable in the SpecialPictureProtocol sample code  
if compiled for garbage collection too.


Can anyone else verify this or point to a workaround?


Looks like a bug somewhere, and I don't see anything obviously wrong  
in your code.


At first I was suspicious because your -startLoading code calls other  
notifications like didReceiveResponse and didFinishLoading. Some  
clients can be confused about that; they aren't prepared for the  
connection to be torn down that early. The usual solution is to do the  
real work using performSelector:@selector(doRealWork) withObject:nil  
afterDelay:0.0, but I tried that and it still crashed.


At this point I expect there's a GC bug in the NSURLProtocol  
machinery, specifically the bridge between NSURLProtocol and  
CFURLProtocol. We'll look further in 7314551.



--
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Custom NSURLProtocol crashes when using Garbage Collection

2009-10-19 Thread Keith Duncan
I wrote a simple NSURLProtocol subclass and started observing crashes  
in URL Loading code. I've extracted the crasher into a simple test  
project which loads an image from a URL with custom scheme which I  
handle every hundredth of a second.


When compiled with -fobjc-gc it reliably crashes; without it runs  
indefinitely however, there are leaked NSString instances allocated by  
NSURLConnection in +sendSynchronousRequest:… I've filed this as rdar://problem/7314551 
 for reference.


The test project can be found http://33software.com/files/CrashLoadingURL.zip 
 The bug is reproductable in the SpecialPictureProtocol sample code  
if compiled for garbage collection too.


Can anyone else verify this or point to a workaround?

Thanks,
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