WebExpress: a system for optimizing Web browsing in a wireless environment
MobiCom '96 Proceedings of the 2nd annual international conference on Mobile computing and networking
Potential benefits of delta encoding and data compression for HTTP
SIGCOMM '97 Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication
Principled design of the modern Web architecture
Proceedings of the 22nd international conference on Software engineering
End-to-end arguments in system design
ACM Transactions on Computer Systems (TOCS)
Rethinking the design of the Internet: the end-to-end arguments vs. the brave new world
ACM Transactions on Internet Technology (TOIT)
Operating Systems, An Advanced Course
Architecture and performance of server-directed transcoding
ACM Transactions on Internet Technology (TOIT)
PRO-COW: Protocol compliance on the web-a longitudinal study
USITS'01 Proceedings of the 3rd conference on USENIX Symposium on Internet Technologies and Systems - Volume 3
Rate of change and other metrics: a live study of the world wide web
USITS'97 Proceedings of the USENIX Symposium on Internet Technologies and Systems on USENIX Symposium on Internet Technologies and Systems
Computer Communications
The effect of consistency on cache response time
IEEE Network: The Magazine of Global Internetworking
| Hi-index | 0.00 |
The simplicity of HTTP was a major factor in the success of the Web. However, as both the protocol and its uses have evolved, HTTP has grown complex. This complexity results in numerous problems, including confused implementors, interoperability failures, difficulty in extending the protocol, and a long specification without much documented rationale.Many of the problems with HTTP can be traced to unfortunate choices about fundamental definitions and models. This paper analyzes the current (HTTP/1.1) protocol design, showing how it fails in certain cases, and how to improve these fundamentals. Some problems with HTTP can be fixed simply by adopting new models and terminology, allowing us to think more clearly about implementations and extensions. Other problems require explicit (but compatible) protocol changes.This paper explains that HTTP needs a clean and consistent data-type model, and in particular needs an explicit 'instance' data type; that HTTP needs a clear data access model, and that resources and instances should carry explicit access-model labels; and that HTTP needs a simple name space for implementations to declare sets of supported extensions.