Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The real answer appears to be creating a custom NSURLProtocol. Should be a straight forward derivation, and add the appropriate proxyHost/proxyPort to the request (along with any other values such as a customized User Agent string). Then, supposedly, all requests will be routed through this custom protocol (including UIWebView requests..direct or derived).</p> <p>relevant samples:</p> <p><a href="https://developer.apple.com/library/ios/samplecode/CustomHTTPProtocol/Introduction/Intro.html#//apple_ref/doc/uid/DTS40013653" rel="nofollow">https://developer.apple.com/library/ios/samplecode/CustomHTTPProtocol/Introduction/Intro.html#//apple_ref/doc/uid/DTS40013653</a></p> <p><a href="http://eng.42go.com/customizing-uiwebview-requests-with-nsurlprotocol/" rel="nofollow">http://eng.42go.com/customizing-uiwebview-requests-with-nsurlprotocol/</a></p> <p>I'll post more when I have the thing operational.</p> <p>Things of note with this implementation.</p> <ol> <li>Initially started using CFNetworking as the "wedge" in my custom NSURLPRotocol, but quickly found I was rewriting the same code that was in ASIHTTPRequest. So I just implemented the wedge with ASIHTTPRequest.</li> <li><p>The items that are not documented well (or at all), is the interaction of UIWebView with NSURLProtocol callbacks, vs NSURLRequest/Conenction with NSURLProtocol. Some Findings:</p> <ul> <li><p>a) All dependent page resources are loaded automatically by UIWebView (which we knew), and they all go through NSURLProtocol, so it is an excellent place to put in code to modify all requests.</p></li> <li><p>b) The UIWebView sets the Referer header. On a redirect, the only way to get the UIWebView to update it's Referer from the original URL to the new redirect URL is with the <code>[[self client] URLProtocol:self wasRedirectedToRequest:redirectRequest redirectResponse:tmpHttpResponse];</code> callback.</p></li> <li><p>c) when the above redirect callback is received by UIWebView, it<br> generates a new NSURLRequest (essentially the one you sent back to<br> it). So if you have a wedge that likes to do the redirect<br> internally, you have to cancel the Request that it attempts to make, in favor of the new one from UIWebView.</p></li> </ul></li> <li><p>You have to be careful with which callbacks you implement from ASIHTTPRequestDelegate. e.g. implementing <code>didReceiveData</code> will disable the built in gzip processing. <code>willRedirectToURL</code> disables most of the built in redirect processing (even if you call <code>[request redirectToURL:newURL];</code> as recommended in the comments).</p></li> </ol>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload