Internet Fascism/Corporatism vs. Internet Libertarianism
When developing enterprise applications you need to consider the networking environment they need to access. Applications that only use internal enterprise networks present challenges as you have to play in their sandbox, after all they own the network. Many of those concerns can be overcome by contacting the right people. It would seem that applications which access the broader Internet would be easier to deal with given the perception of openness on the Internet and the standardization of specifications like HTTP/1.1.
There has been no shortage of stories about governments' intrusive role in the Internet around the globe like China's Great Firewall or the Egyption ISP shutown. Even in the US there are stories of the government restricting access to content, implementing cyber-threat countermeasures and trying to maintain Net Neutrality. Although, Net Neutrality really has less to do with government and more to do with corporations trying to restrict and monetize access to the Internet. However, my recent experience shows some Internet Service Providers (ISP) have already started.
While developing an enterprise application I needed to indicate to the user whether or not the computer was on the internal enterprise network. To do this I decided to have the application perform a web request to another resource (i.e.. computer) that I knew was always available only on the client's network. It did exactly what I wanted to in the client's office. However, when I brought my computer home to test the application I was shocked to find that the application showed that it successfully connected to the server.
I consider the Internet to be anything outside of my house, including my Internet Service Provider (ISP). As such I expect the Internet to be open and follow the HTTP/1.1 specification. However my ISP, Verizon FiOS, rolled out a "feature" a couple years ago that breaks the HTTP/1.1 specification. The specification states that if a requested resource cannot be found then a return code of "404 - Not Found" should be sent back to the requestor. When I used Fiddler to trace the return codes I noticed that the response ended up being "200 - OK" meaning the server was found. However, as you can see in Figure 1 the initial resource I was looking for wasn't found, but instead of 404 return code, my ISP returned a 302 (which should be a 307, but that's another issue). The 302 return code tells the requestor that the requested resource has moved to a new location and the requestor should look there instead. The problem with this is that resource hasn't moved, it is simply not available because it doesn't exist on the Internet.
| Result | Protocol | Host | URL | Body |
| 302 | HTTP | my application FQDN | / | 0 |
| 302 | HTTP | wwwwz.websearch.verizon.net | /wwwwz.websearch.verizon.net/search?qo=my application FQDN... | 0 |
| 307 | HTTP | goto.searchassist.com | /goto.searchassist.com/find?p=paxfire&s=my application FQDN... | 0 |
| 200 | HTTP | find.searchassist.com | /find.searchassist.com/landing.jsf?p=cnksver&q=my application FQDN... | 48,875 |
Apparently Verizon starting doing these redirects to help users when they mistype a URL and then extended it to redirect 404 responses. I can see using this to reduce overall costs by cutting the number of support calls. However, I think this was first and foremost an opportunity to generate ad revenue. Whatever the reason, it breaks the way the open Internet is supposed to work in my opinion, so I decided to turn off Verizon's redirect "feature".
