Yes, those are the search terms that had me scratching my head for several hours today…
You see, once upon a time, we trusted each other on the internet. Internet browsers were built optimistically, that no one would try to do foolish things or cheat anyone.
And then came cross-site scripting attacks. That’s where a nice site, like a banking site, gets attacked remotely simply by virtue of someone making an exploit in a comment field or some other innocuous thing. The browser would start sending data to another computer. That is bad.
So browsers got less trusting. They won’t let you send data to another computer unless that computer says it’s okay. (Wait.. what? Isn’t that backwards?) Oh, ok, so that kind of attack is still possible.
But what it does do is protect you from fake sites (e.g. a domain name where they start out recognizable, like www.mybank .. but then instead of going to dot-com, they go to dot-flibbertygibbet.com..)
But today I wasn’t trying to steal your credit card numbers. Honest. I was trying to make a webview control in a Mac app send some data to a server. It was almost working but I kept getting the error
Searching the internet wasn’t helpful. But I finally found the answer:
This was really handy, because I was using NSURLProtocol to deliver content via a custom sheme anyhow. But that’s a story for another day.
I hope someone finds this useful.
Both GDB and LLDB by default will stop when a debugged process receives a signal. Some libraries, such as the mongoose HTTP server, will generate SIGPIPE as a matter of course and that can be “normal”. However, the debuggers stop anyhow.
Google result currently shows this GDB command can be entered to stop the behavior:
handle SIGPIPE nostop
The LLDB equivalent is not obvious, but I found that this will do it:
process handle SIGPIPE -n true -p true -s false