• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: How should a NSURLProtocol handle a wrong URL?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How should a NSURLProtocol handle a wrong URL?


  • Subject: Re: How should a NSURLProtocol handle a wrong URL?
  • From: Daryle Walker <email@hidden>
  • Date: Fri, 01 Aug 2014 19:17:54 -0400

On Aug 1, 2014, at 7:37 AM, Quinn The Eskimo! <email@hidden> wrote:

>
> On 1 Aug 2014, at 11:58, Daryle Walker <email@hidden> wrote:
>
>> I’m talking about the protocol being passed a wrong scheme, getting a URL with/without an authority (“//“ and a host) but you handle only the other way, misspelled string, etc.
>
> It depends on what your goal is.  Why did you implement the protocol in the first place?  For example, if you're implementing a custom protocol to support HTTP Live Streaming [1], it'd probably be best to return NO from +canInitWithRequest:.  That way NSURL{Session,Connection} will simply act like it would if the protocol wasn't installed. OTOH, if you're overriding HTTPS to implement custom HTTPS server trust evaluation, you don't necessary want the request to fall through to the standard HTTPS implementation, in which case it'd be best to accept the request and then fail it.

It’s not HTTP(S). I was going to start a framework for my protocol, but since I’m building off a web browser, I could add “about:” URLs first, which would give me practice with NSURLProtocol.

Why would the goal matter when dealing with URLs that are so malformed that they shouldn’t be passed to the next step in the process.  I’m thinking in terms of returning nil vs. returning a URL-response object with an error code vs. throwing a exception kinds of stuff.  Should our code be robust enough to deal with a scheme that the NSURLProtocol subclass can’t handle but some other part of the system sent to us by mistake?

> [1] As described in WWDC 2010 Session 403 "Advances in HTTP Live Streaming".

—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


  • Follow-Ups:
    • Re: How should a NSURLProtocol handle a wrong URL?
      • From: "Quinn \"The Eskimo!\"" <email@hidden>
References: 
 >How should a NSURLProtocol handle a wrong URL? (From: Daryle Walker <email@hidden>)
 >Re: How should a NSURLProtocol handle a wrong URL? (From: "Quinn \"The Eskimo!\"" <email@hidden>)

  • Prev by Date: Re: How should a NSURLProtocol handle a wrong URL?
  • Next by Date: Re: How should a NSURLProtocol handle a wrong URL?
  • Previous by thread: Re: How should a NSURLProtocol handle a wrong URL?
  • Next by thread: Re: How should a NSURLProtocol handle a wrong URL?
  • Index(es):
    • Date
    • Thread