There are some uses (especially for ad blocking) to have PAC decide to throw away a URL request (sort of like the IMAP or FTP NOOP). I think the directive "NULL" would be ideal. Right now people do things like PROXY to localhost on a dead port. I've strongly objected to people doing things like hacking /etc/hosts on their systems as a form of ad blocking, so I think any way of allowing people to get what they want without potentially hacking the proverbial nose off their system is a good idea. (These two mechanisms are not the same, but I'm just connecting a general problem with a general solution).
(nathan, if you are going to work on this bug, you can assign ownership to yourself and target a milestone as welll...) From reading the PAC specs, as well as being the only person to propose PAC2, here's my take: PROXY <RESERVED> string should not be used because of possible colisions w/ real hostnames. NULL was just the first word that came into my head. I think "ignore" or "blocked" or something like that would be fine, after all the purpose of the directive is to "throwaway" the URL request gracefully, so all these poor people who are using /etc/hosts to block ads can stop administratively cutting off their nose to save their systems from ads. As for the implementation details you mention, I think you very much should talk to both layout/UI and docshell module owners, because I approached my request purely from a networking perspective. I never figure out how a blocked request should LOOK, either to the network consumer modules, nor to the end user. It might be possible that they would want to add some kind of new error state, like PAC_rejection, because there might be uses for making it distinct from a "real" network error. (For example, I could imagine that some people would want the rejection to happen interactively, which would mean docshell would need to be able to distinguish between PAC blocks and real network problems).
Created attachment 109175 [details] [diff] [review] Patch to allow PAC code to gracefully doom a request (PAC2) Here's a patch in progress to allow the PAC code to deny a URL request in a manner that does not make a request to a (hopefully) unresponsive local port nor cause the display of broken image icons on the users screen. Most of the patch happens in netwerk, but error handling had to be minorly changed in "modules/libpr0n/src/imgLoader.cpp". In private email, email@example.com granted theoretical approval of this change. I've tested this patch only minorly, and only on Linux. The comments starting with "FIXME" are notes to myself that probably will not be in a final patch. But as far as I know, this patch should be safe to apply to a test system.
Created attachment 109177 [details] Sample PAC file showing syntax for DENY This is a sample PAC file to show the syntax of DENY and to illustrate the differences between DENY and proxying to a dead local port. DENY blocks the request without visible error, while proxying to a dead port (unless pref("browser.display.show_image_placeholders", false)) has a broken image icon. Hmm. You can probably use this attachment directly from the web as a PAC file, but (since I'm still typing this) I haven't tried it yet. Else save to a file.
Created attachment 112736 [details] [diff] [review] Second draft patch allowing PAC to deny request Here's another patch with a couple small modifications to account for interim changes to the other source files. I think this is pretty much ready to go. Review would be appreciated. I needed to make a tiny reversion to the patch of nsIOService.cpp for bug #176919, but I think this is fine. It was a giant patch, and this particular change didn't seem to be directly relevant to it. Worth checking, though.
Comment on attachment 112736 [details] [diff] [review] Second draft patch allowing PAC to deny request this patch has rotted.