(lib)microhttpd

libmicrohttpd, project page at gnu.org

License

  • GPL v1.3 “or later”
    “with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts,” slide 19.

Sources

Documentation

  • The GNU libmicrohttpd Reference Manual,
    tl;dr → is helpful.
  • libmicrohttpd (3),
    tl;dr → not helpful, merely credits.
  • Christian Grothoff, GNU libmicrohttpd, 2013-05-30, 19 slides.
  • GNU libmicrohttpd (MHD), undated, 12 pages
    Security Audit Report for the Mozilla Secure Open Source Fund
    pertains to

    • version 0.9.52,
    • commit 938b9b8dae70739c6e629bf144b57b5d6212e6b1

Who

  • Evgeny Grin,
  • Hans Grothoff
  • Sree Hrsha Totakura, listed at INRIA
  • Daniel Pittman, listed, listed in libmicrohttpd (3)

Exemplars

  • GNUnet
  • P2P Portal
  • GNOME Music Player Client
  • Kiwix
  • XMBC
  • OpenVAS
  • Psensor
  • Disk Nukem
  • Flat8
  • Fawkes
  • Conky
  • CallHome
  • OpenDIAS
  • Techne
  • Open Lightning Architecture
  • Cables Communication Project
  • OpenZWave
  • libhttpserver (yes: libhttpserver, no: libhttpserver
  • and more!

Via: slides.

Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture” | Fielding, Taylor, Erenkrantz, Gorlick, Whitehead, Khare, Oreizy

Roy T. Fielding, Richard N. Taylor, Justin Erenkrantz, Michael M. Gorlick, E. James Whitehead, Rohit Khare, Peyman Oreizy; Reflections on the REST Architectural Style and “Principled Design of the Modern Web Architecture; In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017); 2017; pages 4-11 (8 pages); landing.

Performed

Reflections on REST; keynote address; performed at the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017); by one of Roy Fielding, Richard Taylor, Rohit Khare (expect: Rohit Khare); video; 0:47:41; slides (42 slides).

Abstract

Seventeen years after its initial publication at ICSE 2000, the Representational State Transfer (REST) architectural style continues to hold significance as both a guide for understanding how the World Wide Web is designed to work and an example of how principled design, through the application of architectural styles, can impact the development and understanding of large-scale software architecture. However, REST has also become an industry buzzword: frequently abused to suit a particular argument, confused with the general notion of using HTTP, and denigrated for not being more like a programming methodology or implementation framework. In this paper, we chart the history, evolution, and shortcomings of REST, as well as several related architectural styles that it inspired, from the perspective of a chain of doctoral dissertations produced by the University of California’s Institute for Software Research at UC Irvine. These successive theses share a common theme: extending the insights of REST to new domains and, in their own way, exploring the boundary of software engineering as it applies to decentralized software architectures and architectural design. We conclude with discussion of the circumstances, environment, and organizational characteristics that gave rise to this body of work.

Mentions

  • REpresentational State Transfer (REST)
  • Computational REpresentational State Transfer (CREST)
    Computational REST (CREST)
  • Capability Uniform Resource Locator (CURL)
    Capability URL (CURL)
  • COmputAtional State Transfer (COAST)
  • Computing Resource Exchange with Security (COAST)
  • ARRESTED
  • Application Programming Interface (API)
  • Distributed Hash Table (DHT)
  • SIENA (Scalable Internet Event Notification Architectures)
  • XML
  • DHT
  • HTTP
  • REST
  • bit.ly
  • Persistsent Uniform Resource Locator (PURL)
    Persistsent URL (PURL)
  • Notifications
    • e.g. on page transitions
    • HTML ping
    • DOM, onClick, onLoad, onAnything
    • M. Thomson, E. Damaggio, B Raymor. Generic Event Delivery Using HTTP Push. RFC 8030. Internet Engineering Task Force (IETF). 2016.
  • Google Analytics
  • Google Docs
  • Google Sheets
  • AJAX
  • JavaScript
  • HTTP
    • LINK
    • UNLINK
  • Peer-to-Peer (P2P)
  • Decentralized Applications (DAPPs, dApps)
  • Client/Server
  • Web Distributed Authoring and Versioning (WebDAV, WEBDAV)
    • lock-based concurrency control
    • An RPC-based client-server centralized ile system with remote access “over HTTP”
  • Limitations of REST
    • one-shot
    • one-to-one
    • one-way
  • execution engine
  • binding environment
  • COAST
    • Capabilities
      • Services
      • Messaging
      • Interpretation
    • Claims
      • Secure remote code execution (RCE)
      • Live update
      • Novel
      • Monitoring & Traceability
      • Something about refactoring:
        Server abdication, client redelegation, server re-offering (fewer services), client reprogramming of the server.
      • Dynamic Reconfiguration
  • Group Consensus and Simultaneous Agreement (GCSA)
  • WebRTC,
  • Websockets
  • Webhooks
  • HTTP/2
  • Internet of Things (IoT)
  • Content Distrubtion Network (CDN)
  • TrueTime
  • GlobalClock
  • Apache Kafka
  • Amazon Kinesis,
  • Google Cloud Pub/Sub
  • Amazon Lambda,
  • IFTTT
  • ‘assistants’, a natural language conversational product concept, within the buzzy AI business culture. Think: Eliza, that you built in high school.
  • Cassandra
  • NoSQL
  • Federated Learning
  • Merkle Hash Trees (not MHT)
  • Bitcoin
  • <buzz>blockchain</buzz>
  • Git
    • is a decentralized in concept.
    • is not decentrlaized in practice, c.f. GitHub
  • Software-as-a-Service (SaaS)
  • Computational REpresentational State Transfer (CREST)
  • Aura
  • Nikander
  • Trickles
  • network continuations
  • Hypertext Transport Protocol (HTTP)
    • HTTP/1.1
    • HTTP/2
  • DARPA
  • NSF
  • ISR (Irvine Software Rationalization?)
  • Arcadia

Behavior, Asynchrony, State, Execution (BASE)

Concept

Adapability requires the design-time  actions…

LP1
making the parts that are subject to change identifiable, discrete and manipulable.
LP2
providing mechanisms for controlling interactions between the parts subject to change.
LP3
providing techniques for managing state.

Elaborated

  • Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor. Runtime Software Adaptation: Framework, Approaches, and Styles. In Companion of 30th International Conference on Software Engineering (ICSE Companion). 2008. ACM. pages 899–910.
  • Richard N. Taylor, Nenad Medvidovic, Peyman Oreizy. Architectural Styles for Runtime Software Adaptation. In Proceedings of the Eighth Joint Working IEEE/IFIP Conference on Software Architecture and Third European Conference on Software Architecture. IEEE Computer Society, 171–180. 2009.

Exemplars

  • C2
  • CREST
  • MapReduce
  • Pipe-and-Filter
  • Event Notifications
  • “and others.”

Disambiguation

  1. within the transaction formalization of Database Theory
    • Basically Available, Soft state, Eventual consistency (BASE)
      not as used herein.
    • a consistency model wherein everything almost works
      riposte: “eventually we are all dead.”
    • Contra
      • Always Computing In Denial (ACID)
      • Atomicity Consistency Isolation Durability (ACID)
  2. within the Dynamic Software Architectures Theory, page 9.
    • Behavior
    • Asynchrony
    • State
    • Execution
  3. within the ARRESTED Theory, page 10.
    the “mindset” of a node in a distributed network.
    Best-Effort
    Others are making their best effort, as are you.
    Approximate
    There is only approximate knowledge of the state of The Other; your theory of mind is limited & foggy, slacky-latent.
    Self-centered
    Others are self-centered, as are you.
    Efficient
    Make efficient use of the only global resource: communication bandwidth to others; i.e. time is the only finite resource.

Asynchronous, Routed, REpresentational State Transfer with Estimation & Delgation (A+R+REST+E+D, ARRESTED)

  • Polling (and its inverse Asynchrony)
  • Asynchrony (and its inverse Polling)
  • Routing
  • Delegation
  • Estimation

Concept

Theory
REST+P
REST with Polling.
REST+E
REST with Estimation.
A+REST
REST with Asynchrony (callbacks).
R+REST
REST with Routing (packets).
REST+D
REST with Delegation (proxies, gateways).
ARREST
Asynchronous, Routed, REST.
ARREST+E
Asynchronous, Routed, REST, with Estimation.
ARREST+D
Asynchronous, Routed, REST, with Delgation.
ARREST+D
Asynchronous, Routed, REST, with Estimation & Delgation.
ARRESTED
A synonym for slow, yes?
Topology

The metaphor.

Poles
North
Centralized Systems
East
Estimated Systems
South
Decentralized Systems
West
Distributed Systems
Boundaries
now horizon
  • Master-Slave Styles
  • Peer-to-Peer Styles
agency boundary
  • Consensus-Based Styles
  • Consensus-Free Styles

Elaborated

Techniques

  • Bitcoin
  • and other distributed ledger schemes.

Computational REpresentational State Transfer (CREST)

Is just like functional programming.

  • The Poetry
    • mashups of Web culture are “the same as” continuations in programming language theory & culture. c.f. Scheme & SML
    • 300-series redirects are continuations

Principles

CP1
The key abstraction of computation is a resource, named by an URL.
CP2
The representation of a resource is a program, a closure, a continuation, or a binding environment plus metadata to describe the program, closure, continuation, or binding environment.
CP3
All computations are context-free.
CP4
Only a few primitive operations are always available, but additional per-resource operations are also encouraged.
CP5
The presence of intermediaries is promoted.

Concept

  • Ship code+data as a package to evaluate off-box (over there, on their box).
  • Receive code+data as a package to evaluate on-box (here on our box).
  • What could go possibly wrong here? [over there?]

Elaborations

  • Justin R. Erenkrantz. Computational REST: A New Model for Decentralized, Internet-Scale Applications. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA. 2009.
  • Justin R. Erenkrantz, Michael Gorlick, Girish Suryanarayana, Richard N. Taylor. Harmonizing Architectural Dissonance in REST-based Architectures. Technical Report UCI-ISR-06-18. Institute for Software Research, University of California, Irvine. 2006.
  • Justin R. Erenkrantz, Michael M. Gorlick, Girish Suryanarayana, Richard N. Taylor. From Representations to Computations: The Evolution of Web Architectures. In ACM SIGSOFT Symposium on The Foundations of Software Engineering (FSE). 2007. pages 255–264.
  • Roy T. Fielding. Maintaining distributed hypertext infostructures: Welcome to MOMspider’s Web. In Computer Networks and ISDN Systems, 27, 2. 1994. pages 193–204. doi:10.1016/0169-7552(94)90133-3. Series title? Selected Papers of the First World-Wide Web Conference.

Techniques

  • web mashups
  • session management
  • cookies in client/server interactions
    <quote>, and the (misplaced) role of cookies in client/server interactions</quote>
  • time-dependent resources; e.g. weather forecasts.
  • time-series responses; e.g. stock tickers.

<editorial>Why aren’t cookies necessary again? They uniquely number the consumer base. They are used to develop Measurement, Targeting, Retargeting & Profiling which are the explicit and probably only renumerative use case of the (online) media business model. Oh, right, and paywalls. And, um, public televison-type “membership drive” tip jars.</editorial>

References

There are 59 references.

Abstracted

  • Roy T. Fielding, Richard N. Taylor. Principled Design of the Modern Web Architecture. In Proceedings of the 22nd International Conference on Software Engineering (ICSE). 2000. pages 407–416. IEEE, Limerick, Ireland.

Dissertated

  • Justin R. Erenkrantz. Computational REST: A New Model for Decentralized, Internet-Scale Applications. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA. 2009.
  • Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. Ph.D. Dissertation. University of California, Irvine, California, USA. 2000.
  • Michael Martin Gorlick. Computational State Transfer: An Architectural Style for Decentralized Systems. Ph.D. Dissertation. Technical Report UCI-ISR-16-3. University of California, Irvine, Irvine, California, USA. 2016.
  • David Alan Halls. Applying Mobile Code to Distributed Systems. Ph.D. Dissertation. University of Cambridge, Cambridge, UK. 1997.
  • Michael Hicks. Dynamic Software Updating. Ph.D. Dissertation. Computer and Information Science, University of Pennsylvania, Philadelphia, Pennsylvania, USA. 2001.
  • Rohit Khare. Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems. Ph.D. Dissertation. University of California, Irvine, California, USA. 2003.
  • Mark Samuel Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. Ph.D. Dissertation. Johns Hopkins University, Baltimore, Maryland, USA. 2006.
  • Peyman Oreizy. Open architecture software: a flexible approach to decentralized software evolution. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA.
  • Emmet James Whitehead, Jr. An Analysis of the Hypertext Versioning Domain. Ph.D. Dissertation. Univ. of California, Irvine, Irvine, California, USA. 2000.

Complete

  1. T. Aura, P. Niklander. Stateless Connections. In Proceedings of the First International Conference on Information and Communication Security (Lecture Notes In Computer Science), Y. Han, T. Okamoto, S. Qing (editors), Vol. 1334. Springer-Verlag, 1997. pages 87–97.
  2. Tim Berners-Lee, Robert Cailliau, Ari Luotonen, Henrik Frystyk Nielsen, Arthur Secret. The World-Wide Web. In Communications of the ACM, 37, 8. 1994-08. pages 76–82. doi:10.1145/179606.179671.
  3. Tim Berners-Lee, Roy T. Fielding, Larry Masinter. Uniform Resource Identifier (URI): Generic Syntax. RFC 3986. Internet Engineering Task Force (IETF). 2005-01. doi:10.17487/RFC3986.
  4. Tim Berners-Lee, Roy T. Fielding, Henrik Frystyk Nielsen. Hypertext Transfer Protocol – HTTP/1.0. RFC 1945. Internet Engineering Task Force (IETF). 1996-05. doi:10.17487/RFC1945.
  5. Tim Berners-Lee, Jean-Francois Groff. The World Wide Web (a.k.a. WWW). In SIGBIO Newsletter, 12, 3. 1992-09. pages 37–40. doi:10.1145/147126.147133.
  6. Keith Bonawitz, Vladimir Ivanov, Ben Kreuter, Antonio Marcedone, H. Brendan McMahan, Sarvar Patel, Daniel Ramage, Aaron Segal, Karn Seth. Practical Secure Aggregation for Federated Learning on User-Held Data. In Proceedings of the NIPS Workshop on Private Multi-Party Machine Learning. 2016. landing.
  7. Antonio Carzaniga, David S. Rosenblum, Alexander L. Wolf. Design and Evaluation of a Wide-Area Event Notification Service. In ACM Transactions on Computer Systems, 19, 3. 2001-08. pages 332–383. paywall.
  8. James C. Corbett, Jeffrey Dean et. al. Spanner: Google’s Globally-distributed Database. In Proceedings of the 10th USENIX Conference on Operating Systems Design and Implementation (OSDI). 2012. pages 251–264. paywall, landing. slides: pptx, event: session.
  9. Chris Dixon. Crypto Tokens: A Breakthrough in Open Network Design. In His Blog, centrally hosted on Medium. 2017-06.
  10. L. Dusseault. HTTP Extensions for Web Distributed Authoring and Versioning (WEBDAV). RFC 4918. Internet Engineering Task Force (IETF). 2007.
  11. Justin R. Erenkrantz. Computational REST: A New Model for Decentralized, Internet-Scale Applications. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA. 2009.
  12. Justin R. Erenkrantz, Michael Gorlick, Girish Suryanarayana, Richard N. Taylor. Harmonizing Architectural Dissonance in REST-based Architectures. Technical Report UCI-ISR-06-18. Institute for Software Research, University of California, Irvine. 2006.
  13. Justin R. Erenkrantz, Michael M. Gorlick, Girish Suryanarayana, Richard N. Taylor. From Representations to Computations: The Evolution of Web Architectures. In ACM SIGSOFT Symposium on The Foundations of Software Engineering (FSE). 2007. pages 255–264.
  14. Roy T. Fielding. Maintaining distributed hypertext infostructures: Welcome to MOMspider’s Web. In Computer Networks and ISDN Systems, 27, 2. 1994. pages 193–204. doi:10.1016/0169-7552(94)90133-3. Series title? Selected Papers of the First World-Wide Web Conference.
  15. Roy T. Fielding. Relative Uniform Resource Locators. RFC 1808. Internet Engineering Task Force (IETF). 1995-06. doi:10.17487/RFC1808.
  16. Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. Ph.D. Dissertation. University of California, Irvine, California, USA. 2000.
  17. Roy T. Fielding, Gail Kaiser. The Apache HTTP Server Project. In IEEE Internet Computing. 1, 4. 1997-07. pages 88–90. doi:10.1109/4236.612229
  18. Roy T. Fielding, Henrik Frystyk Nielsen, Jeffrey Mogul, Jim Gettys, Tim Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. RFC 2068. 1997-01. doi:10.17487/RFC2068
  19. Roy T. Fielding, Julian Reschke. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC 7231. Internet Engineering Task Force (IETF). 2014-06. doi:10.17487/RFC7231.
  20. Roy T. Fielding, Richard N. Taylor. Principled Design of the Modern Web Architecture. In Proceedings of the 22nd International Conference on Software Engineering. 2000. pages 407–416. IEEE, Limerick, Ireland.
  21. Roy T. Fielding, Richard N. Taylor. Principled Design of the Modern Web Architecture. In ACM Transactions on Internet Technology, 2, 2. 2002-05. pages 115–150.
  22. Roy T. Fielding, E. James Whitehead, Jr., Kenneth M. Anderson, Gregory A. Bolcer, Peyman Oreizy, Richard N. Taylor. Web-Based Development of Complex Information Products. In Communications of the ACM, 41, 8. 1998-08. pages 84–92.
  23. Matias Giorgio, Richard N. Taylor. Accountability Through Architecture for Decentralized Systems: A Preliminary Assessment. Technical Report UCI-ISR-15-2. Institute for Software Research, University of California, Irvine. 2015.
  24. Cristiano Giuffrida, Anton Kuijsten, Andrew S. Tanenbaum. 2013. Safe and Automatic Live Update for Operating Systems. In Proceedings of the Eighteenth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS’13). ACM, New York City, New York, USA, 279–292.
  25. Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. HTTP Extensions for Distributed Authoring – WEBDAV. RFC 2518. Internet Engineering Task Force. 1999.
  26. Michael Martin Gorlick. Computational State Transfer: An Architectural Style for Decentralized Systems. Ph.D. Dissertation. Technical Report UCI-ISR-16-3. University of California, Irvine, Irvine, California, USA. 2016.
  27. Michael M. Gorlick, Kyle Strasser, Richard N. Taylor. COAST: An Architectural Style for Decentralized On-Demand Tailored Services. In Proceedings of 2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture (WICSA/ECSA). 2012. pages 71–80.
  28. David Alan Halls. Applying Mobile Code to Distributed Systems. Ph.D. Dissertation. University of Cambridge, Cambridge, UK. 1997.
  29. Michael Hicks. Dynamic Software Updating. Ph.D. Dissertation. Computer and Information Science, University of Pennsylvania, Philadelphia, Pennsylvania, USA. 2001.
  30. Irvine Research Unit in Software (IRUS). The Workshop on Internet-Scale Technology (TWIST). A series, 1998-2000.
  31. R. Kadia. Issues Encountered in Building a Flexible Software Development Environment: Lessons from the Arcadia Project. In Proceedings of the Fifth ACM SIGSOFT Symposium on Software Development Environments (SDE). 1992. ACM, New York, NY, USA. pages 169–180. doi:10.1145/142868.143768.
  32. Rohit Khare. Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems. Ph.D. Dissertation. University of California, Irvine, California, USA. 2003.
  33. Rohit Khare, Richard N. Taylor. Extending the REpresentational State Transfer Architectural Style for Decentralized Systems. In Proceedings of the 26th International Conference on Software Engineering (ICSE). 2004. IEEE Computer Society, Edinburgh, Scotland, UK. pages 428–437.
  34. Avinash Lakshman, Prashant Malik. Cassandra: A Decentralized Structured Storage System. In SIGOPS Operating Systems Review, 44, 2. 2010-04. pages 35–40.
  35. David Mazieres. The stellar consensus protocol: A federated model for internet-level consensus. Stellar Development Foundation. 2015.
  36. Mark Samuel Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. Ph.D. Dissertation. Johns Hopkins University, Baltimore, Maryland, USA. 2006.
  37. Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.
  38. Peyman Oreizy. Open architecture software: a flexible approach to decentralized software evolution. Ph.D. Dissertation. University of California, Irvine, Irvine, California, USA.
  39. Peyman Oreizy, Michael M. Gorlick, Richard N. Taylor, Dennis Heimbigner, Gregory Johnson, Nenad Medvidovic, Alex Quilici, David Rosenblum. An Architecture-based Approach to Self-Adaptive Software. In IEEE Intelligent Systems, 14, 3. 1999-05 (May-June). pages 54–62.
  40. Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor. Architecture-Based Runtime Software Evolution. In Proceedings of the 20th International Conference on Software Engineering (ICSE). 1998. pages 177–186.
  41. Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor. Runtime Software Adaptation: Framework, Approaches, and Styles. In Companion of 30th International Conference on Software Engineering (ICSE Companion). 2008. ACM. pages 899–910.
  42. Peyman Oreizy, Richard N. Taylor. 1998. On the role of software architectures in runtime system reconfiguration. In IEE Proceedings-Software, 145, 5. 1998. pages 137–145.
  43. Dewayne E. Perry, Alexander L. Wolf. 1992. Foundations for the Study of Software Architecture. In SIGSOFT Software Engineering Notes, 17, 4. 1992-10. pages 40–52. doi:10.1145/141874.141884.
  44. Sean Rhea, Brighten Godfrey, Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, Harlan Yu. OpenDHT: A Public DHT Service and Its Uses. In SIGCOMM Computing Communication Review, 35, 4. 2005-08. pages 73–84.
  45. Alan Shieh, Andrew C. Myers, Emin G. Sirer. Trickles: A Stateless Network Stack for Improved Scalability, Resilience, and Flexibility. In Proceedings of Symposium on Networked Systems Design and Implementation,/em> (NSDI), Vol. 2. USENIX Association. 2005. pages 175–188.
  46. Alan Shieh, Andrew C. Myers, Emin Gün Sirer. A Stateless Approach to Connection-Oriented Protocols. In ACM Transactions on Computer Systems, 26, 3. 2008-09. pages 8:1–8:50.
  47. James W. Stamos, David K. Gifford. Implementing Remote Evaluation. In IEEE Transactions on Software Engineering, 16, 7. 1990-07. pages 710–722.
  48. James W. Stamos, David K. Gifford. Remote Evaluation. In ACM Transactions on Programming Languages and Systems (TOPLAS), 12, 4. 1990-10. pages 537–564.
  49. Chengzheng Sun, Xiaohua Jia, Yanchun Zhang, Yun Yang, David Chen. Achieving Convergence, Causality Preservation, and Intention Preservation in Real-time Cooperative Editing Systems. In ACM Transactions on Complicating Human Interactions (HCI), 5, 1. 1998-03. pages 63–108.
  50. Richard N. Taylor, Nenad Medvidovic, et al. A Component- and Message- Based Architectural Style for GUI Software. In Transactions on Software Engineering. 1996-06. pages 390–406.
  51. Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy. Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons. 2010. ASIN:B012AQ8M42: Kindle: no, paper: $151-$600.
  52. Richard N. Taylor, Nenad Medvidovic, Peyman Oreizy. Architectural Styles for Runtime Software Adaptation. In Proceedings of the Eighth Joint Working IEEE/IFIP Conference on Software Architecture and Third European Conference on Software Architecture. IEEE Computer Society, 171–180. 2009.
  53. R.D. Tennant. 1976. The Denotational Semantics of Programming Languages. In Communications of the ACM 19, 8. 1976-08. pages 437–453.
  54. M. Thomson, E. Damaggio, B Raymor. Generic Event Delivery Using HTTP Push. RFC 8030. Internet Engineering Task Force (IETF). 2016.
  55. Emmet James Whitehead, Jr. An Analysis of the Hypertext Versioning Domain. Ph.D. Dissertation. Univ. of California, Irvine, Irvine, California, USA. 2000.
  56. Emmet James Whitehead, Jr., Yaron Goland. The WebDAV Property Design. In Software, Practice and Experience 34 2004, 135–161.
  57. Wikipedia. 2017. Representational state transfer,/a>. In Wikipedia. 2017.
  58. Scott Wolchok, J Alex Halderman. Crawling BitTorrent DHTs for Fun and Profit. In Proceedings of the Fourth USENIX Workshop on Offensive Technologies (WOOT10). 2010.
  59. Gavin Wood. 2014. Ethereum: A secure decentralised generalised transaction ledger. Paper 151. Ethereum Project Yellow Papers 2014.

Previously filled.

RFC 7624 – Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement

RFC 7624Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement; R. Barnes, B. Schneier, C. Jennings, T. Hardie, B. Trammell, C. Huitema, D. Borkmann; IETF; 2015-08.

tl;dr
  • state-level actors
    (police- & military-focused)
  • some mention of adtrade tracking
    (is passive, pervasive & persistent but nominally T&C, N&C, etc.)

Abstract

Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks.

Table of Contents

1. Introduction
2. Terminology
3. An Idealized Passive Pervasive Attacker
3.1. Information Subject to Direct Observation
3.2. Information Useful for Inference
3.3. An Illustration of an Ideal Passive Pervasive Attack
3.3.1. Analysis of IP Headers
3.3.2. Correlation of IP Addresses to User Identities
3.3.3. Monitoring Messaging Clients for IP Address Correlation
3.3.4. Retrieving IP Addresses from Mail Headers
3.3.5. Tracking Address Usage with Web Cookies
3.3.6. Graph-Based Approaches to Address Correlation
3.3.7. Tracking of Link-Layer Identifiers
4. Reported Instances of Large-Scale Attacks
5. Threat Model
5.1. Attacker Capabilities
5.2. Attacker Costs
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
IAB Members at the Time of Approval
Acknowledgements
Authors’ Addresses

Mentioned

Concepts

  • Encryption
  • Snowden
  • National Security Agency (NSA)
    • FOXACID
    • PRISM
    • QUANTUM
    • XKEYSCORE

<quote>
3.3.2. Correlation of IP Addresses to User Identities

The correlation of IP addresses with specific users can be done in various ways. For example, tools like reverse DNS lookup can be used to retrieve the DNS names of servers. Since the addresses of servers tend to be quite stable and since servers are relatively less numerous than users, an attacker could easily maintain its own copy of the DNS for well-known or popular servers to accelerate such lookups.

On the other hand, the reverse lookup of IP addresses of users is generally less informative. For example, a lookup of the address currently used by one author’s home network returns a name of the form “c-192-000-002-033.hsd1.wa.comcast.net”. This particular type of reverse DNS lookup generally reveals only coarse-grained location or provider information, equivalent to that available from geolocation databases.

In many jurisdictions, Internet Service Providers (ISPs) are required to provide identification on a case-by-case basis of the “owner” of a specific IP address for law enforcement purposes. This is a reasonably expedient process for targeted investigations, but pervasive surveillance requires something more efficient. This provides an incentive for the attacker to secure the cooperation of the ISP in order to automate this correlation.

Even if the ISP does not cooperate, user identity can often be obtained via inference. POP3 [RFC1939] and IMAP [RFC3501] are used to retrieve mail from mail servers, while a variant of SMTP is used to submit messages through mail servers. IMAP connections originate from the client, and typically start with an authentication exchange in which the client proves its identity by answering a password challenge. The same holds for the SIP protocol [RFC3261] and many instant messaging services operating over the Internet using proprietary protocols.

The username is directly observable if any of these protocols operate in cleartext; the username can then be directly associated with the source address.

3.3.4. Retrieving IP Addresses from Mail Headers

SMTP [RFC5321] requires that each successive SMTP relay adds a “Received” header to the mail headers. The purpose of these headers is to enable audit of mail transmission, and perhaps to distinguish between regular mail and spam. Here is an extract from the headers of a message recently received from the perpass mailing list:

Received: from 192-000-002-044.zone13.example.org (HELO ?192.168.1.100?) (xxx.xxx.xxx.xxx)
    by lvps192-000-002-219.example.net
    with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 27 Oct 2013 21:47:14 +0100
Message-ID: >526D7BD2.7070908@example.org>
Date: Sun, 27 Oct 2013 20:47:14 +0000
From: Some One <some.one@example.org>

This is the first “Received” header attached to the message by the first SMTP relay; for privacy reasons, the field values have been anonymized. We learn here that the message was submitted by “Some One” on October 27, from a host behind a NAT (192.168.1.100) [RFC1918] that used the IP address 192.0.2.44. The information remained in the message and is accessible by all recipients of the perpass mailing list, or indeed by any attacker that sees at least one copy of the message.

An attacker that can observe sufficient email traffic can regularly update the mapping between public IP addresses and individual email identities. Even if the SMTP traffic was encrypted on submission and relaying, the attacker can still receive a copy of public mailing lists like perpass.

3.3.5. Tracking Address Usage with Web Cookies

Many web sites only encrypt a small fraction of their transactions. A popular pattern is to use HTTPS for the login information, and then use a “cookie” to associate following cleartext transactions with the user’s identity. Cookies are also used by various advertisement services to quickly identify the users and serve them with “personalized” advertisements. Such cookies are particularly useful if the advertisement services want to keep tracking the user across multiple sessions that may use different IP addresses.

As cookies are sent in cleartext, an attacker can build a database that associates cookies to IP addresses for non-HTTPS traffic. If the IP address is already identified, the cookie can be linked to the user identify. After that, if the same cookie appears on a new IP address, the new IP address can be immediately associated with the predetermined identity.

3.3.6. Graph-Based Approaches to Address Correlation

An attacker can track traffic from an IP address not yet associated with an individual to various public services (e.g., web sites, mail servers, game servers) and exploit patterns in the observed traffic to correlate this address with other addresses that show similar patterns. For example, any two addresses that show connections to the same IMAP or webmail services, the same set of favorite web sites, and game servers at similar times of day may be associated with the same individual. Correlated addresses can then be tied to an individual through one of the techniques above, walking the “network graph” to expand the set of attributable traffic.

3.3.7. Tracking of Link-Layer Identifiers

Moving back down the stack, technologies like Ethernet or Wi-Fi use MAC (Media Access Control) addresses to identify link-level destinations. MAC addresses assigned according to IEEE 802 standards are globally unique identifiers for the device. If the link is publicly accessible, an attacker can eavesdrop and perform tracking. For example, the attacker can track the wireless traffic at publicly accessible Wi-Fi networks. Simple devices can monitor the traffic and reveal which MAC addresses are present. Also, devices do not need to be connected to a network to expose link-layer identifiers. Active service discovery always discloses the MAC address of the user, and sometimes the Service Set Identifiers (SSIDs) of previously visited networks. For instance, certain techniques such as the use of “hidden SSIDs” require the mobile device to broadcast the network identifier together with the device identifier. This combination can further expose the user to inference attacks, as more information can be derived from the combination of MAC address, SSID being probed, time, and current location. For example, a user actively probing for a semi-unique SSID on a flight out of a certain city can imply that the user is no longer at the physical location of the corresponding AP. Given that large-scale databases of the MAC addresses of wireless access points for geolocation purposes have been known to exist for some time, the attacker could easily build a database that maps link-layer identifiers and time with device or user identities, and use it to track the movement of devices and of their owners. On the other hand, if the network does not use some form of Wi-Fi encryption, or if the attacker can access the decrypted traffic, the analysis will also provide the correlation between link-layer identifiers such as MAC addresses and IP addresses. Additional monitoring using techniques exposed in the previous sections will reveal the correlation between MAC addresses, IP addresses, and user identity. For instance, similarly to the use of web cookies, MAC addresses provide identity information that can be used to associate a user to different IP addresses.

</quote>

References

Normative

  • RFC 6973Privacy Considerations for Internet Protocols, A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, R. Smith, DOI 10.17487/RFC6973, 2013-07.

Informative

Mostly newspaper articles (expos’ees) & techreport whitepapers.

  • RFC 1035Domain names – implementation and specification, P. Mockapetris, STD 13, RFC 1035, doi:10.17487/RFC1035, 1987-11.
  • RFC 1918Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, BCP 5, RFC 1918, doi:10.17487/RFC1918, 1996-02.
  • RFC 1939Post Office Protocol – Version 3, J. Myers, M. Rose, STD 53, RFC 1939, doi:10.17487/RFC1939, 1996-05.
  • RFC 3261SIP: Session Initiation Protocol, J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, RFC 3261, doi:10.17487/RFC3261, 2002-06.
  • RFC 3365Strong Security Requirements for Internet Engineering Task Force Standard Protocols, J. Schiller, BCP 61, RFC 3365, doi:10.17487/RFC3365, 2002-08.
  • RFC 3501INTERNET MESSAGE ACCESS PROTOCOL – VERSION 4rev1, M. Crispin, RFC 3501, doi:10.17487/RFC3501, 2003-03.
  • RFC 4033DNS Security Introduction and Requirements, R. Arends, Austein, R., Larson, M., Massey, D., and S. Rose, RFC 4033, doi:10.17487/RFC4033, 2005-03.
  • RFC 4303IP Encapsulating Security Payload (ESP), S. Kent, RFC 4303, doi:10.17487/RFC4303, 2005-12.
  • RFC 4949Internet Security Glossary, Version 2, R. Shirey, FYI 36, RFC 4949, doi:10.17487/RFC4949, 2007-08.
  • RFC 5246The Transport Layer Security (TLS) Protocol Version 1.2, T. Dierks, E. Rescorla, RFC 5246, doi:10.17487/RFC5246, 2008-08.
  • RFC 5321Simple Mail Transfer Protocol, J. Klensin, RFC 5321, doi:10.17487/RFC5321, 2008-10.
  • RFC 6962Certificate Transparency, B. Laurie, A. Langley, E. Kasper, RFC 6962, doi:10.17487/RFC6962, 2013-06.
  • RFC 7011Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information, B. Claise, B. Trammell, (editors), P. Aitken, STD 77, RFC 7011, doi:10.17487/RFC7011, 2013-09.
  • RFC 7258Pervasive Monitoring Is an Attack, S. Farrell, H. Tschofenig, BCP 188, RFC 7258, doi:10.17487/RFC7258, 2014-05.

Via: backfill.

Header Enrichment or ISP Enrichment? Emerging Privacy Threats in Mobile Networks | Vallina-Rodriguez, Sundaresan, Kreibich, Paxson

Narseo Vallina-Rodriguez, Srikanth Sundaresan, Christian Kreibich, Vern Paxson; Header Enrichment or ISP Enrichment? Emerging Privacy Threats in Mobile Networks; In Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Middleboxes and Network Function Virtualization (HotMiddlebox 2015, huh? now you’re just being silly); 2015-08-17; 6 pages; landing.

Abstract

HTTP header enrichment allows mobile operators to annotate HTTP connections via the use of a wide range of request headers. Operators employ proxies to introduce such headers for operational purposes, and—as recently widely publicized—also to assist advertising programs in identifying the subscriber responsible for the originating traffic, with significant consequences for the user’s privacy. In this paper, we use data collected by the Netalyzr network troubleshooting service over 16 months to identify and characterize HTTP header enrichment in modern mobile networks. We present a timeline of HTTP header usage for 299 mobile service providers from 112 countries, observing three main categories:

  1. unique user and device identifiers (e.g., IMEI and IMSI)
  2. headers related to advertising programs, and
  3. headers associated with network operations.

Mentions

  • HTTP header enrichment
  • Netalyzr
    • Netalyzer-for-Android
  • Verizon Precision Marketingt Insights
  • The IETF’s Service Function Chaining (SFC) standards are vague about whether injected headers are good or bad (should be removed).
  • Data
    • Collected: 2013-11 → 2015-03.
    • 112 countries
    • 299 operators
  • CRAWDAD
  • Belief: no M?NO is yet cracking TLS to insert HTTP headers into the encrypted stream.
  • Suggested as an ID-less methods of identification: device-unique allocation of the (routable) IPv6 space to identify the device, in addition to routing to it.
  • RFC 7239Forwarded HTTP Extension; A. Peterson, M. Milsson (Opera); IETF; 2014-06.
  • Cessation Timeline
    • 2014-10 → Vodaphone (ZA) has ceased their practices in 2014-10, nothing to see there, now.
    • 2014-11 → AT&T has ceased their practices 2014-11.
    • 2015-03 → Verion was not respecting opt-out (as evidenced by not inserting the X-UIDH header) through 2015-03.
  • Continuation
    • Verion continues the X-UIDH header insertion.
  • The X-Forwarded-For header carries extra freight in T-Mobile (DE)
  • Carrier-Grade NAT (CGN) at 100.64.0.0/10 per RFC 6598IANA-Reserved IPv4 Prefix for Shared Address Space (2012-04)

Headers

Table 1 & Table 2; Table 3 (not shown)

HTTP Header Operator Country Estimated Purpose
x-up-calling-line-id Vodacom ZA Phone Number
x-up-nai
x-up-vodacomgw-subid
msisdn Orange JO MISDN
x-nokia-msisdn Smart PH
tm_user-id Movistar ES Subscriber ID
x-up-subno
x-up-3gpp-imeisv Vodacom ZA IMEI
lbs-eventtime Smarttone HK Timestamp
lbs-zoneid Location
x-acr AT&T US unstated, an identifier
x-amobee-1 Airtel IN
x-amobee-2 Singtel SG
x-uidh Verizon US
x-vf-acr Vodacom ZA
Vodafone NL

Argot

  • Access Point Name (APN)
  • GPRS
  • HTTP
  • IMSI
  • IMEI
  • J2ME
  • Location-Based Services (LBS)
  • Mobile Country Code (MCC)
  • Mobile Network Code (MNC)
  • Mobile Network Operator (MNO)
  • Mobile Virtual Network Operator (MVNO)
  • MSISDN
  • Hong Kong Metro (subway) (MTR)
  • Service Function Chaining (SFC)
  • SIM
  • Transport-Layer Security (TLS)
  • Unique Identifier (UID); contra the specific UUID or GUID
  • Virtual Private Network (VPN)
  • WAP

References

A significant number of newpaper articles, vulgarizations & bloggist opinements.

Proxygen by Facebook, a C++ HTTP Framework

Daniel Sommermann, Alan Frindell (Facebook); Introducing Proxygen, Facebook’s C++ HTTP Framework; In Their Blog; 2014-11-09.

Mentions

Assessment

Summary
Language LOC App LOC Test LOC
am 695 572 123
c++ 47,712 35,075 12,637
py 163 163 0
sh 84 84 0
total 48,654 35,894 12,760

Language (C++)

  • C++11
  • In-class initializers
  • Uniform Initialization
    • brace-enclosed initializers
    • in-class initializers
  • move semantics
  • namespaces
  • const
  • return value optimization (functions returning containers)
  • seems formatted for 80 character teletype screens.
  • std::unique_ptr
  • bool as single bitfield
  • range for loop
  • auto
  • std::string in lieu of char * (sometimes)
  • std::vector in lieu of arrays (sometimes)
  • attributes
    • final
    • ifunc (indirect function, per ELF)
    • noexcept
    • override
    • __attribute__((constructor))
  • static_assert
  • std::function
  • std::thread
  • std::chrono (seconds, milliseconds)

Dependencies

Runtime
Buildtime
  • Python
  • Ruby
  • gperf

Physical Design

  • (outline) function definitions separated from the function declaration (mostly)
  • roughly one class per file
  • Suffixes
    • *.hpp
    • *.cpp

Build System

  • autotools (automake, autoconf)
  • doxygen

Portability

  • Ubuntu

Promotion

Via: backfill

Actualities

CoreProxygenArchitecture.png

Inventory

LOC File
264 ./proxygen/proxygen/configure.ac
27 ./proxygen/proxygen/httpserver/Makefile.am
10 ./proxygen/proxygen/httpserver/samples/echo/Makefile.am
1 ./proxygen/proxygen/httpserver/samples/Makefile.am
1 ./proxygen/proxygen/lib/http/codec/Makefile.am
135 ./proxygen/proxygen/lib/http/Makefile.am
1 ./proxygen/proxygen/lib/http/session/Makefile.am
13 ./proxygen/proxygen/lib/Makefile.am
29 ./proxygen/proxygen/lib/services/Makefile.am
28 ./proxygen/proxygen/lib/ssl/Makefile.am
62 ./proxygen/proxygen/lib/utils/Makefile.am
1 ./proxygen/proxygen/Makefile.am
2381 ./proxygen/proxygen/external/http_parser/http_parser_cpp.cpp
319 ./proxygen/proxygen/external/http_parser/http_parser.h
3142 ./proxygen/proxygen/external/http_parser/test.c
59 ./proxygen/proxygen/httpserver/filters/DirectResponseHandler.h
125 ./proxygen/proxygen/httpserver/Filters.h
106 ./proxygen/proxygen/httpserver/filters/RejectConnectFilter.h
92 ./proxygen/proxygen/httpserver/HTTPServerAcceptor.cpp
48 ./proxygen/proxygen/httpserver/HTTPServerAcceptor.h
205 ./proxygen/proxygen/httpserver/HTTPServer.cpp
142 ./proxygen/proxygen/httpserver/HTTPServer.h
86 ./proxygen/proxygen/httpserver/HTTPServerOptions.h
78 ./proxygen/proxygen/httpserver/Mocks.h
186 ./proxygen/proxygen/httpserver/RequestHandlerAdaptor.cpp
74 ./proxygen/proxygen/httpserver/RequestHandlerAdaptor.h
76 ./proxygen/proxygen/httpserver/RequestHandlerFactory.h
99 ./proxygen/proxygen/httpserver/RequestHandler.h
198 ./proxygen/proxygen/httpserver/ResponseBuilder.h
84 ./proxygen/proxygen/httpserver/ResponseHandler.h
56 ./proxygen/proxygen/httpserver/samples/echo/EchoHandler.cpp
47 ./proxygen/proxygen/httpserver/samples/echo/EchoHandler.h
87 ./proxygen/proxygen/httpserver/samples/echo/EchoServer.cpp
41 ./proxygen/proxygen/httpserver/samples/echo/EchoStats.h
192 ./proxygen/proxygen/httpserver/ScopedHTTPServer.h
36 ./proxygen/proxygen/httpserver/SignalHandler.cpp
37 ./proxygen/proxygen/httpserver/SignalHandler.h
218 ./proxygen/proxygen/lib/http/codec/CodecDictionaries.h
92 ./proxygen/proxygen/lib/http/codec/CodecProtocol.cpp
51 ./proxygen/proxygen/lib/http/codec/CodecProtocol.h
409 ./proxygen/proxygen/lib/http/codec/compress/GzipHeaderCodec.cpp
96 ./proxygen/proxygen/lib/http/codec/compress/GzipHeaderCodec.h
128 ./proxygen/proxygen/lib/http/codec/compress/HeaderCodec.h
46 ./proxygen/proxygen/lib/http/codec/compress/Header.h
61 ./proxygen/proxygen/lib/http/codec/compress/HeaderPiece.h
210 ./proxygen/proxygen/lib/http/codec/compress/HeaderTable.cpp
221 ./proxygen/proxygen/lib/http/codec/compress/HeaderTable.h
105 ./proxygen/proxygen/lib/http/codec/compress/HPACKCodec.cpp
56 ./proxygen/proxygen/lib/http/codec/compress/HPACKCodec.h
50 ./proxygen/proxygen/lib/http/codec/compress/HPACKConstants.h
59 ./proxygen/proxygen/lib/http/codec/compress/HPACKContext.cpp
58 ./proxygen/proxygen/lib/http/codec/compress/HPACKContext.h
105 ./proxygen/proxygen/lib/http/codec/compress/HPACKDecodeBuffer.cpp
84 ./proxygen/proxygen/lib/http/codec/compress/HPACKDecodeBuffer.h
167 ./proxygen/proxygen/lib/http/codec/compress/HPACKDecoder.cpp
78 ./proxygen/proxygen/lib/http/codec/compress/HPACKDecoder.h
112 ./proxygen/proxygen/lib/http/codec/compress/HPACKEncodeBuffer.cpp
94 ./proxygen/proxygen/lib/http/codec/compress/HPACKEncodeBuffer.h
155 ./proxygen/proxygen/lib/http/codec/compress/HPACKEncoder.cpp
75 ./proxygen/proxygen/lib/http/codec/compress/HPACKEncoder.h
36 ./proxygen/proxygen/lib/http/codec/compress/HPACKHeader.cpp
81 ./proxygen/proxygen/lib/http/codec/compress/HPACKHeader.h
345 ./proxygen/proxygen/lib/http/codec/compress/Huffman.cpp
138 ./proxygen/proxygen/lib/http/codec/compress/Huffman.h
158 ./proxygen/proxygen/lib/http/codec/compress/Logging.cpp
39 ./proxygen/proxygen/lib/http/codec/compress/Logging.h
111 ./proxygen/proxygen/lib/http/codec/compress/StaticHeaderTable.cpp
24 ./proxygen/proxygen/lib/http/codec/compress/StaticHeaderTable.h
39 ./proxygen/proxygen/lib/http/codec/ErrorCode.cpp
52 ./proxygen/proxygen/lib/http/codec/ErrorCode.h
124 ./proxygen/proxygen/lib/http/codec/FlowControlFilter.cpp
97 ./proxygen/proxygen/lib/http/codec/FlowControlFilter.h
1071 ./proxygen/proxygen/lib/http/codec/HTTP1xCodec.cpp
196 ./proxygen/proxygen/lib/http/codec/HTTP1xCodec.h
49 ./proxygen/proxygen/lib/http/codec/HTTPChecks.cpp
38 ./proxygen/proxygen/lib/http/codec/HTTPChecks.h
263 ./proxygen/proxygen/lib/http/codec/HTTPCodecFilter.cpp
175 ./proxygen/proxygen/lib/http/codec/HTTPCodecFilter.h
468 ./proxygen/proxygen/lib/http/codec/HTTPCodec.h
74 ./proxygen/proxygen/lib/http/codec/HTTPSettings.cpp
71 ./proxygen/proxygen/lib/http/codec/HTTPSettings.h
16 ./proxygen/proxygen/lib/http/codec/SettingsId.cpp
44 ./proxygen/proxygen/lib/http/codec/SettingsId.h
1584 ./proxygen/proxygen/lib/http/codec/SPDYCodec.cpp
378 ./proxygen/proxygen/lib/http/codec/SPDYCodec.h
163 ./proxygen/proxygen/lib/http/codec/SPDYConstants.cpp
130 ./proxygen/proxygen/lib/http/codec/SPDYConstants.h
81 ./proxygen/proxygen/lib/http/codec/SPDYUtil.cpp
144 ./proxygen/proxygen/lib/http/codec/SPDYUtil.h
16 ./proxygen/proxygen/lib/http/codec/SPDYVersion.h
47 ./proxygen/proxygen/lib/http/codec/SPDYVersionSettings.h
33 ./proxygen/proxygen/lib/http/codec/TransportDirection.cpp
28 ./proxygen/proxygen/lib/http/codec/TransportDirection.h
61 ./proxygen/proxygen/lib/http/HTTPCommonHeaders.template.h
167 ./proxygen/proxygen/lib/http/HTTPConnector.cpp
152 ./proxygen/proxygen/lib/http/HTTPConnector.h
32 ./proxygen/proxygen/lib/http/HTTPConstants.cpp
67 ./proxygen/proxygen/lib/http/HTTPConstants.h
31 ./proxygen/proxygen/lib/http/HTTPException.cpp
169 ./proxygen/proxygen/lib/http/HTTPException.h
308 ./proxygen/proxygen/lib/http/HTTPHeaders.cpp
423 ./proxygen/proxygen/lib/http/HTTPHeaders.h
34 ./proxygen/proxygen/lib/http/HTTPHeaderSize.h
831 ./proxygen/proxygen/lib/http/HTTPMessage.cpp
98 ./proxygen/proxygen/lib/http/HTTPMessageFilters.h
724 ./proxygen/proxygen/lib/http/HTTPMessage.h
45 ./proxygen/proxygen/lib/http/HTTPMethod.cpp
59 ./proxygen/proxygen/lib/http/HTTPMethod.h
34 ./proxygen/proxygen/lib/http/ProxygenErrorEnum.cpp
73 ./proxygen/proxygen/lib/http/ProxygenErrorEnum.h
81 ./proxygen/proxygen/lib/http/RFC2616.cpp
73 ./proxygen/proxygen/lib/http/RFC2616.h
23 ./proxygen/proxygen/lib/http/session/AckLatencyEvent.h
33 ./proxygen/proxygen/lib/http/session/ByteEvents.cpp
105 ./proxygen/proxygen/lib/http/session/ByteEvents.h
171 ./proxygen/proxygen/lib/http/session/ByteEventTracker.cpp
85 ./proxygen/proxygen/lib/http/session/ByteEventTracker.h
67 ./proxygen/proxygen/lib/http/session/CodecErrorResponseHandler.cpp
42 ./proxygen/proxygen/lib/http/session/CodecErrorResponseHandler.h
122 ./proxygen/proxygen/lib/http/session/HTTPDirectResponseHandler.cpp
52 ./proxygen/proxygen/lib/http/session/HTTPDirectResponseHandler.h
89 ./proxygen/proxygen/lib/http/session/HTTPDownstreamSession.cpp
73 ./proxygen/proxygen/lib/http/session/HTTPDownstreamSession.h
34 ./proxygen/proxygen/lib/http/session/HTTPErrorPage.cpp
70 ./proxygen/proxygen/lib/http/session/HTTPErrorPage.h
47 ./proxygen/proxygen/lib/http/session/HTTPEvent.cpp
126 ./proxygen/proxygen/lib/http/session/HTTPEvent.h
102 ./proxygen/proxygen/lib/http/session/HTTPSessionAcceptor.cpp
141 ./proxygen/proxygen/lib/http/session/HTTPSessionAcceptor.h
71 ./proxygen/proxygen/lib/http/session/HTTPSessionController.h
2002 ./proxygen/proxygen/lib/http/session/HTTPSession.cpp
832 ./proxygen/proxygen/lib/http/session/HTTPSession.h
25 ./proxygen/proxygen/lib/http/session/HTTPSessionStats.h
933 ./proxygen/proxygen/lib/http/session/HTTPTransaction.cpp
118 ./proxygen/proxygen/lib/http/session/HTTPTransactionEgressSM.cpp
71 ./proxygen/proxygen/lib/http/session/HTTPTransactionEgressSM.h
1155 ./proxygen/proxygen/lib/http/session/HTTPTransaction.h
134 ./proxygen/proxygen/lib/http/session/HTTPTransactionIngressSM.cpp
73 ./proxygen/proxygen/lib/http/session/HTTPTransactionIngressSM.h
116 ./proxygen/proxygen/lib/http/session/HTTPUpstreamSession.cpp
95 ./proxygen/proxygen/lib/http/session/HTTPUpstreamSession.h
66 ./proxygen/proxygen/lib/http/session/SimpleController.cpp
66 ./proxygen/proxygen/lib/http/session/SimpleController.h
162 ./proxygen/proxygen/lib/http/session/TransportFilter.cpp
124 ./proxygen/proxygen/lib/http/session/TransportFilter.h
27 ./proxygen/proxygen/lib/http/session/TTLBAStats.h
96 ./proxygen/proxygen/lib/http/Window.cpp
84 ./proxygen/proxygen/lib/http/Window.h
59 ./proxygen/proxygen/lib/services/AcceptorConfiguration.h
444 ./proxygen/proxygen/lib/services/Acceptor.cpp
342 ./proxygen/proxygen/lib/services/Acceptor.h
56 ./proxygen/proxygen/lib/services/ConnectionCounter.h
54 ./proxygen/proxygen/lib/services/HTTPAcceptor.h
45 ./proxygen/proxygen/lib/services/LoadShedConfiguration.cpp
109 ./proxygen/proxygen/lib/services/LoadShedConfiguration.h
60 ./proxygen/proxygen/lib/services/NetworkAddress.h
40 ./proxygen/proxygen/lib/services/RequestWorker.cpp
89 ./proxygen/proxygen/lib/services/RequestWorker.h
126 ./proxygen/proxygen/lib/services/ServerSocketConfig.h
58 ./proxygen/proxygen/lib/services/ServiceConfiguration.h
33 ./proxygen/proxygen/lib/services/Service.cpp
137 ./proxygen/proxygen/lib/services/Service.h
102 ./proxygen/proxygen/lib/services/ServiceWorker.h
66 ./proxygen/proxygen/lib/services/TransportInfo.cpp
279 ./proxygen/proxygen/lib/services/TransportInfo.h
160 ./proxygen/proxygen/lib/services/WorkerThread.cpp
129 ./proxygen/proxygen/lib/services/WorkerThread.h
24 ./proxygen/proxygen/lib/ssl/ClientHelloExtStats.h
53 ./proxygen/proxygen/lib/ssl/DHParam.h
31 ./proxygen/proxygen/lib/ssl/PasswordInFile.cpp
38 ./proxygen/proxygen/lib/ssl/PasswordInFile.h
23 ./proxygen/proxygen/lib/ssl/SSLCacheOptions.h
69 ./proxygen/proxygen/lib/ssl/SSLCacheProvider.h
95 ./proxygen/proxygen/lib/ssl/SSLContextConfig.h
654 ./proxygen/proxygen/lib/ssl/SSLContextManager.cpp
186 ./proxygen/proxygen/lib/ssl/SSLContextManager.h
354 ./proxygen/proxygen/lib/ssl/SSLSessionCacheManager.cpp
293 ./proxygen/proxygen/lib/ssl/SSLSessionCacheManager.h
42 ./proxygen/proxygen/lib/ssl/SSLStats.h
76 ./proxygen/proxygen/lib/ssl/SSLUtil.cpp
102 ./proxygen/proxygen/lib/ssl/SSLUtil.h
308 ./proxygen/proxygen/lib/ssl/TLSTicketKeyManager.cpp
198 ./proxygen/proxygen/lib/ssl/TLSTicketKeyManager.h
20 ./proxygen/proxygen/lib/ssl/TLSTicketKeySeeds.h
60 ./proxygen/proxygen/lib/utils/CobHelper.h
76 ./proxygen/proxygen/lib/utils/CryptUtil.cpp
22 ./proxygen/proxygen/lib/utils/CryptUtil.h
84 ./proxygen/proxygen/lib/utils/DestructorCheck.h
71 ./proxygen/proxygen/lib/utils/DomainNameMisc.h
34 ./proxygen/proxygen/lib/utils/Exception.cpp
46 ./proxygen/proxygen/lib/utils/Exception.h
358 ./proxygen/proxygen/lib/utils/FilterChain.h
43 ./proxygen/proxygen/lib/utils/HTTPTime.cpp
20 ./proxygen/proxygen/lib/utils/HTTPTime.h
16 ./proxygen/proxygen/lib/utils/NullTraceEventObserver.cpp
23 ./proxygen/proxygen/lib/utils/NullTraceEventObserver.h
159 ./proxygen/proxygen/lib/utils/ParseURL.cpp
112 ./proxygen/proxygen/lib/utils/ParseURL.h
242 ./proxygen/proxygen/lib/utils/Result.h
38 ./proxygen/proxygen/lib/utils/SocketOptions.cpp
24 ./proxygen/proxygen/lib/utils/SocketOptions.h
46 ./proxygen/proxygen/lib/utils/StateMachine.h
37 ./proxygen/proxygen/lib/utils/TestUtils.h
128 ./proxygen/proxygen/lib/utils/Time.h
32 ./proxygen/proxygen/lib/utils/TraceEventContext.h
130 ./proxygen/proxygen/lib/utils/TraceEvent.cpp
139 ./proxygen/proxygen/lib/utils/TraceEvent.h
24 ./proxygen/proxygen/lib/utils/TraceEventObserver.h
24 ./proxygen/proxygen/lib/utils/UtilInl.h
163 ./proxygen/proxygen/lib/utils/gen_trace_event_constants.py
54 ./proxygen/proxygen/deps.sh
30 ./proxygen/proxygen/reinstall.sh
11 ./proxygen/proxygen/httpserver/tests/Makefile.am
21 ./proxygen/proxygen/lib/http/codec/test/Makefile.am
21 ./proxygen/proxygen/lib/http/session/test/Makefile.am
14 ./proxygen/proxygen/lib/http/test/Makefile.am
16 ./proxygen/proxygen/lib/ssl/test/Makefile.am
27 ./proxygen/proxygen/lib/test/Makefile.am
13 ./proxygen/proxygen/lib/utils/test/Makefile.am
97 ./proxygen/proxygen/httpserver/samples/echo/test/EchoHandlerTest.cpp
154 ./proxygen/proxygen/httpserver/tests/HTTPServerTest.cpp
35 ./proxygen/proxygen/lib/http/codec/compress/test/HeaderPieceTests.cpp
134 ./proxygen/proxygen/lib/http/codec/compress/test/HeaderTableTests.cpp
345 ./proxygen/proxygen/lib/http/codec/compress/test/HPACKBufferTests.cpp
283 ./proxygen/proxygen/lib/http/codec/compress/test/HPACKCodecTests.cpp
202 ./proxygen/proxygen/lib/http/codec/compress/test/HPACKContextTests.cpp
65 ./proxygen/proxygen/lib/http/codec/compress/test/HPACKHeaderTests.cpp
96 ./proxygen/proxygen/lib/http/codec/compress/test/HTTPArchive.cpp
37 ./proxygen/proxygen/lib/http/codec/compress/test/HTTPArchive.h
312 ./proxygen/proxygen/lib/http/codec/compress/test/HuffmanTests.cpp
146 ./proxygen/proxygen/lib/http/codec/compress/test/LoggingTests.cpp
212 ./proxygen/proxygen/lib/http/codec/compress/test/RFCExamplesTests.cpp
61 ./proxygen/proxygen/lib/http/codec/compress/test/TestUtil.cpp
28 ./proxygen/proxygen/lib/http/codec/compress/test/TestUtil.h
222 ./proxygen/proxygen/lib/http/codec/test/FilterTests.cpp
130 ./proxygen/proxygen/lib/http/codec/test/HTTP1xCodecTest.cpp
130 ./proxygen/proxygen/lib/http/codec/test/MockHTTPCodec.h
1228 ./proxygen/proxygen/lib/http/codec/test/SPDYCodecTest.cpp
207 ./proxygen/proxygen/lib/http/codec/test/TestUtils.cpp
237 ./proxygen/proxygen/lib/http/codec/test/TestUtils.h
226 ./proxygen/proxygen/lib/http/session/test/DownstreamTransactionTest.cpp
1367 ./proxygen/proxygen/lib/http/session/test/HTTPDownstreamSessionTest.cpp
154 ./proxygen/proxygen/lib/http/session/test/HTTPSessionAcceptorTest.cpp
226 ./proxygen/proxygen/lib/http/session/test/HTTPSessionMocks.h
71 ./proxygen/proxygen/lib/http/session/test/HTTPSessionTest.h
153 ./proxygen/proxygen/lib/http/session/test/HTTPTransactionMocks.h
169 ./proxygen/proxygen/lib/http/session/test/HTTPTransactionSMTest.cpp
1411 ./proxygen/proxygen/lib/http/session/test/HTTPUpstreamSessionTest.cpp
1368 ./proxygen/proxygen/lib/http/session/test/MockCodecDownstreamTest.cpp
41 ./proxygen/proxygen/lib/http/session/test/TestUtils.cpp
34 ./proxygen/proxygen/lib/http/session/test/TestUtils.h
463 ./proxygen/proxygen/lib/http/test/HTTPMessageTest.cpp
49 ./proxygen/proxygen/lib/http/test/MockHTTPMessageFilter.h
128 ./proxygen/proxygen/lib/http/test/RFC2616Test.cpp
124 ./proxygen/proxygen/lib/http/test/WindowTest.cpp
83 ./proxygen/proxygen/lib/services/test/AcceptorTest.cpp
278 ./proxygen/proxygen/lib/ssl/test/SSLCacheTest.cpp
88 ./proxygen/proxygen/lib/ssl/test/SSLContextManagerTest.cpp
635 ./proxygen/proxygen/lib/test/TestAsyncTransport.cpp
158 ./proxygen/proxygen/lib/test/TestAsyncTransport.h
23 ./proxygen/proxygen/lib/test/TestMain.cpp
49 ./proxygen/proxygen/lib/utils/test/CryptUtilTest.cpp
538 ./proxygen/proxygen/lib/utils/test/GenericFilterTest.cpp
54 ./proxygen/proxygen/lib/utils/test/HTTPTimeTest.cpp
42 ./proxygen/proxygen/lib/utils/test/MockTime.h
137 ./proxygen/proxygen/lib/utils/test/ParseURLTest.cpp
73 ./proxygen/proxygen/lib/utils/test/ResultBenchmark.cpp
112 ./proxygen/proxygen/lib/utils/test/ResultTest.cpp
22 ./proxygen/proxygen/lib/utils/test/UtilTest.cpp