Nicholas Zakas has a great writeup explaining a web browser to non-technical people. I thought I'd take this opportunity to explain what a web browser is to web developers.
At the heart of it, a web browser is two things. It is a program that can communicate with a web server using the HTTP protocol, and it is a program that can render HTML and other associated content types... except that it might not care to. As web developers looking out at the world through the window of a TCP socket on port 80, all we see is an agent on the other end issuing GET and POST requests. What it does with our responses, we don't really know. We do our best to cater to what we can identify. We look at user-agent strings to build statistics of the kinds of browsers that visit our site, and we use JavaScript to detect capabilities that we can use to enhance the experience that we deliver, but what if that JavaScript were never executed and the user-agent string were a lie?
No, at the heart of it, a web browser is just one thing — an HTTP client.
Built upon this HTTP client could be various entities. A real web rendering engine, a crawling bot, an audio browser, a web service client, or a script kiddie using curl. While it may be impossible to know of all possible entities on the other end, as web developers, we must build applications that are prepared to deal with anything.
We use progressive enhancement to create an engaging experience for genuine users of our site regardless of the capabilities of the user agent they use. We validate everything that comes in over that HTTP connection to prevent the destruction or degradation of our service either by malice or accident, and we trust nothing that comes in from the other end. Not the POST data, not the query string, not the cookies, not the request time, and certainly not the user agent string.
Do we assume our users are the kind that Nicholas describes or do we assume that they're all out to destroy us, or perhaps somewhere in between? The reality is that we have to build our sites for all of them. Start with HTTP and progressively enhance from there.
/bb|[^b]{2}/
Never stop Grokking
Wednesday, October 13, 2010
Labels
2fa
4.01-strict
404
accessibility
acer
airport wifi
algorithm
android
apache
API
att
audio
australia
authentication
ayttm
badges
bandwidth
bbc
bcp
berlin
bigsur
blog
blogger
blogger template
bof
book
boomerang
broken
bug
byte order
c
caching
chrome
closure
cmc
cms
codepo8
colours
comic strip
comments
communication
compile
conference
confoo
congestion-control
cookies
correlation
couchdb
cracker
crash
creative
credit card
crockford
cron
crux
csrf
css
curl
cwv
data tags
database
date
db
delicious
design
developer
dhtml
dns
docker
dom
dopplr
dragdrop
DST
dynamic script node
education
email
emotion
endianness
entities
ephemeral ports
epicondylitis
error checking
esmtp
everybuddy
extensions
facebook
favicon
fc9
fedora
fidelity
filesystem
firefox
firesheep
flickr
flot
form
forms
fosdem
foss
foss.in
freebsd
freedom
freestyle
ftp
function currying
gdb
geek
geo
george
gmail
gnome
google
gradient
groupon
hack
hacker
hardy
hash
howtos
htc
html
html5
http
i18n
icici
ie
iit
im
innerHTML
instant messaging
interfaces
internet
internet explorer
ios
ip
ip address
ipc
iphone
ipv6
iso8601
ISP
jabber
javascript
jslint
json
julia
keynote
latency
latex
LC_TIME
lcp
linux
load
localisation
login
lsm
luhn
MAC
macosx
mail
mathematics
mathjax
measurement
media queries
meetup
memory
messaging
microformats
missing kids
mobile
montreal
movable type
mp3
mvc
mysql
name generator
navtiming
network
nexus
nodejs
notes
opensource
opera
partition
passwords
pdf
perception
performance
perl
phone
php
planet
png
ports
prerender
printing
privacy
programming
programming style
progressive enhancement
psychology
puzzle
recovery
redhat
regex
regular expressions
resource timing
review
rfc2822
rfc3339
rhel
roundtrip
rss
rum
rwd
safari
sampling
scalability
scripting
search
secnet
security
sed
segfault
self extracting tarball
sendmail
seo
server
shell
shell script
sigdashes
site
slideshare
smtp
soap
sockets
spoofing
SQL
ssl
starttls
startup
statistics
stoyan
strftime
stubbornella
sydney
sysadmin
tablespace
talks
tcp
tcp-slow-start
testing
theme
thisisbroken
thisisfixed
thoughts
throughput
tim berners-lee
timezone
tips
toc
toy
transactions
twitter
two factor auth
typing
ubuntu
ui
unicode
unix
url
usability
ux
velocity
vint cerf
w3c
wav
web
web services
webcam
webdev
webdu
webkit
webperf
webtiming
whois
widgets
wifi
windows
workaround
write performance
X
xss
yahoo
ydn
YQL
yslow
yui
Translate this page
- PHOTO FEED
- Blog feed bluesmoon@Mastodon
- © PHILIP TELLIS
The other side of the moon by Philip Tellis is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
3 comments :
From what I can understand, what you say in your article is: you can have no expectations of a client.
Well, I agree up to a point, but what you need to consider is standards. So, for example, the client says ‘I'm able to understand HTML5’. And from that point on, you can and you should expect the client to be able to process your response correctly, accordingly to the standard. If it doesn't, then it's not your fault and obviously not your problem.
@Skan I don't think users and business care who's problem it is - stuff must work regardless.
@Skan, my point is that it could be a malicious user on the other end using curl or a script that they wrote, but pretending to understand HTML5 so that you'll send them certain features. They'll then send you a crafted request to try and compromise your service.
Right at the bottom layer (the HTTP layer), you need to make sure you deal with this. At layers above this (HTML, CSS, Javascript, Ajax), you can do client side capabilities detection to enhance user experience.
Post a Comment