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 <third, fourth, etc option here :)> > On Apr 11, 2015, at 10:09 PM, David Grant <dmgr...@infinitydigital.com> 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 <danc...@rebelbase.com> 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 <img src="xyz:///show_me_my_image.jpg"> 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 <dmgr...@infinitydigital.com> >>> 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 <danc...@rebelbase.com> wrote: >>>> >>>> an npapi plugin on a web page, it registers a protocol handler >>>> >>>> On Apr 11, 2015, at 2:26 AM, Mike Abdullah <mabdul...@karelia.com> wrote: >>>> >>>> >>>> On 11 Apr 2015, at 02:28, Dan S <danc...@rebelbase.com> 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/dmgrant%40infinitydigital.com >>>> >>>> This email sent to dmgr...@infinitydigital.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/dmgrant%40infinitydigital.com >> >> This email sent to dmgr...@infinitydigital.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
