Performance Evaluation of HTTP Web Servers in Embedded Systems

Total Page:16

File Type:pdf, Size:1020Kb

Performance Evaluation of HTTP Web Servers in Embedded Systems Performance evaluation of HTTP web servers in embedded systems DANIEL LIND Master of Science Thesis Stockholm, Sweden 2014 2 Prestandautvärdering av HTTP webbservrar i inbyggda system av Daniel Lind Examensarbete MMK 2014:05 MDA 442 KTH Industriell teknik och management Maskinkonstruktion SE-100 44 STOCKHOLM 3 Performance evaluation of HTTP web servers in embedded systems Daniel Lind Master of Science Thesis MMK 2014:05 MDA 442 KTH Industrial Engineering and Management Machine Design SE-100 44 STOCKHOLM 4 Examensarbete MMK 2014:05 MDA 442 Prestandautvärdering av HTTP webbservrar i inbyggda system Daniel Lind Godkänt Examinator Handledare 2014-02-23 Martin Edin Grimheden Sagar Behere Uppdragsgivare Kontaktperson Syntronic AB Mladen Nikitovic Sammanfattning Detta examensarbete utfördes i samarbete med Syntronic AB. Syftet var att utröna vilken prestanda som kunde uppnås med Hypertext Transfer Protocol (HTTP) servrar på utvalda hårdvaruplattformar för inbyggda system. Resultatet skulle vara användbart för den som ska välja en hårdvaruplattform till ett inbyggt system med en HTTP-server, och utvärderingen innehöll därför beteende under belastning, belastningsgränser, samt användning av systemresurser. Prestandamätningar användes för att generera data för analys, och en förstudie utfördes för att bestämma vilka plattformar, funktionalitet och prestandaparametrar som skulle ingå i studien. Tre hårdvaruplattformar med olika prestandanivåer - BeagleBoard-xM, STK1000 och Syntronic Midrange - valdes ut. En simulerad webapplikation användes under testen och totalt testades fem HTTP-serverprogramvaror. BeagleBoard-xM med BusyBox httpd hade totalt sett den bästa prestandan vid körning av testapplikationen. Den hade en hög överbelastningspunkt, korta behandlingstider samt överlägset beteende under överbelastning. Midrange med en modifierad version av en server skapad av Stefano Oliveri presterade dock bättre när den inte var överbelastad. STK1000 presterade klart sämre än de andra plattformarna. Beteendet under överbelastning och effektiviteten i utnyttjandet av systemresurer skilde sig kraftigt åt mellan de olika servrarna. Testresultaten visade också att det var stor skillnad mellan HTTP-serverprogramvarorna som kördes på samma hårdvaruplatform, och generellt sett presterade programvaror med ett begränsat antal funktioner bäst. 5 Master of Science Thesis MMK 2014:05 MDA 442 Performance evaluation of HTTP web servers in embedded systems Daniel Lind Approved Examiner Supervisor 2014-02-23 Martin Edin Grimheden Sagar Behere Commissioner Contact person Syntronic AB Mladen Nikitovic Abstract This Masters Thesis was carried out in cooperation with Syntronic AB. The purpose was to determine what was possible in terms of Hypertext Transfer Protocol (HTTP) server performance on selected hardware platforms for embedded systems. The results should be valuable for those who are about to select a hardware platform for an embedded system that will contain a HTTP server, and the evaluation therefore included load limits, performance characteristics and system resource usage. The required data was gathered with performance measurements, and a pre-study was performed to decide on platforms, functionality and performance parameters to include in the study. Three hardware platforms with different levels of performance - BeagleBoard-xM, STK1000 and Syntronic Midrange - were selected. A simulated web application was used during the tests and a total of five HTTP server software were tested. BeagleBoard-xM with BusyBox httpd had the best overall performance when running the test application. It had a high overload point, low connection durations when not overloaded, and a superior overload behavior. However, Midrange with a modified version of a server made by Stefano Oliveri performed better when not overloaded. STK1000 was far behind the other two platforms in terms of performance. The overload behavior and efficiency of system resource usage differed greatly between the servers. The test results also showed that the performance varied significantly between HTTP server software running on the same hardware platform, and generally the software with limited feature sets performed best. 6 Acknowledgements I would like to express my gratitude to the people who have supported me during the work with this thesis: ● Examiner: Mats Hanson, KTH ● Supervisors: Sagar Behere, KTH and Mladen Nikitovic, Syntronic AB ● David Näslund, Syntronic AB Stockholm June 14, 2013, Daniel Lind 7 Table of Contents 1. Introduction.....................................................................................................................10 1.1 Background................................................................................................................10 1.2 Problem description....................................................................................................11 1.3 Purpose......................................................................................................................11 1.4 Methodology...............................................................................................................11 1.5 Delimitations...............................................................................................................12 1.6 Pre-study results.........................................................................................................13 2. Available HTTP server software.....................................................................................15 2.1 Barracuda Embedded Web Server.............................................................................17 2.2 yaSSL Embedded Web Server...................................................................................17 2.3 Boa Webserver...........................................................................................................17 2.3.1 Comments...........................................................................................................18 2.4 KLone.........................................................................................................................18 2.5 Fusion Embedded™ HTTPS......................................................................................18 2.6 BusyBox httpd.............................................................................................................18 2.6.1 Comments...........................................................................................................18 2.7 Appweb™...................................................................................................................19 2.8 Cherokee....................................................................................................................20 2.9 thttpd - tiny/turbo/throttling HTTP server.....................................................................20 2.9.1 Comments...........................................................................................................20 2.10 Lighttpd.....................................................................................................................21 2.11 HTTP servers built on top of lwIP..............................................................................21 3. Measuring embedded HTTP server performance.........................................................22 3.1 Performance parameters............................................................................................22 3.2 Factors affecting measurement results.......................................................................22 3.2.1 The server...........................................................................................................23 3.2.2 The network........................................................................................................24 3.2.3 The web application............................................................................................25 3.2.4 The clients...........................................................................................................25 3.2.5 Conclusions.........................................................................................................26 3.3 Preparation.................................................................................................................26 3.4 Measurement methodology........................................................................................26 3.5 Tools...........................................................................................................................27 4. Test environment.............................................................................................................28 4.1 Client..........................................................................................................................28 4.2 Servers.......................................................................................................................28 4.2.1 BeagleBoard-xM.................................................................................................28 4.2.2 STK1000.............................................................................................................29 4.2.3 Midrange.............................................................................................................30 5. Test methodology............................................................................................................31 5.1 Simulated web application, instrument panel..............................................................31
Recommended publications
  • BOROUGH of MANHATTAN COMMUNITY COLLEGE City University of New York Department of Computer Information Systems Office S150/Phone: 212-220-1476
    BOROUGH OF MANHATTAN COMMUNITY COLLEGE City University of New York Department of Computer Information Systems Office S150/Phone: 212-220-1476 Web Programming II Class hours: 2 CIS 485 Lab hours: 2 Spring 2012 Credits: 3 Course Description: This course will introduce students to server-side web programming. Emphasis is placed on database connectivity in order to solve intermediate level application problems. Students will be tasked with web projects that facilitate understanding of tier design and programming concepts. The overall goal of this course is to create a shopping cart application with a login and database component. Prerequisites/Co-requisite: Basic Skills: ENG 088, ESL 062, ACR 094, MAT 012/051; CIS 385 Web Programming I Learning Outcomes and Assessment After completing this course, students will be able to: Outcome: Demonstrate the use of a database with server-side scripting Assessment: Lab exercises and exam questions Outcome: Demonstrate the use a Cookie and Session manager with server-side scripting Assessment: Final project, lab exercises and exam questions Outcome: Develop a database-driven website Assessment: Lab exercises Outcome: Design and develop a shopping-cart application with a login and database component Assessment: Final Project General Education Outcomes and Assessment Quantitative Skills – Students will use quantitative skills and concepts and methods of mathematics to solve problems Assessment: Use formulas and concepts of mathematics to solve problems in programming assignments Information and Technology
    [Show full text]
  • Dynamic Web Pages with the Embedded Web Server
    Dynamic Web Pages With The Embedded Web Server The Digi-Geek’s AJAX Workbook (NET+OS, XML, & JavaScript) Version 1.0 5/4/2011 Page 1 Copyright Digi International, 2011 Table of Contents Chapter 1 - How to Use this Guide ............................................................................................................... 5 Prerequisites – If You Can Ping, You Can Use This Thing! ..................................................................... 5 Getting Help with TCP/IP and Wi-Fi Setup ............................................................................................ 5 The Study Guide or the Short Cut? ....................................................................................................... 5 C Code ................................................................................................................................................... 6 HTML Code ............................................................................................................................................ 6 XML File ................................................................................................................................................. 6 Provide us with Your Feedback ............................................................................................................. 6 Chapter 2 - The Server-Client Relationship ................................................................................................... 7 Example – An Analogy for a Normal HTML page .................................................................................
    [Show full text]
  • Effects and Opportunities of Native Code Extensions For
    Effects and Opportunities of Native Code Extensions for Computationally Demanding Web Applications DISSERTATION zur Erlangung des akademischen Grades Dr. Phil. im Fach Bibliotheks- und Informationswissenschaft eingereicht an der Philosophischen Fakultät I Humboldt-Universität zu Berlin von Dipl. Inform. Dennis Jarosch Präsident der Humboldt-Universität zu Berlin: Prof. Dr. Jan-Hendrik Olbertz Dekan der Philosophischen Fakultät I: Prof. Michael Seadle, Ph.D. Gutachter: 1. Prof. Dr. Robert Funk 2. Prof. Michael Seadle, Ph.D. eingereicht am: 28.10.2011 Tag der mündlichen Prüfung: 16.12.2011 Abstract The World Wide Web is amidst a transition from interactive websites to web applications. An increasing number of users perform their daily computing tasks entirely within the web browser — turning the Web into an important platform for application development. The Web as a platform, however, lacks the computational performance of native applications. This problem has motivated the inception of Microsoft Xax and Google Native Client (NaCl), two independent projects that fa- cilitate the development of native web applications. Native web applications allow the extension of conventional web applications with compiled native code, while maintaining operating system portability. This dissertation determines the bene- fits and drawbacks of native web applications. It also addresses the question how the performance of JavaScript web applications compares to that of native appli- cations and native web applications. Four application benchmarks are introduced that focus on different performance aspects: number crunching (serial and parallel), 3D graphics performance, and data processing. A performance analysis is under- taken in order to determine and compare the performance characteristics of native C applications, JavaScript web applications, and NaCl native web applications.
    [Show full text]
  • AMNESIA 33: How TCP/IP Stacks Breed Critical Vulnerabilities in Iot
    AMNESIA:33 | RESEARCH REPORT How TCP/IP Stacks Breed Critical Vulnerabilities in IoT, OT and IT Devices Published by Forescout Research Labs Written by Daniel dos Santos, Stanislav Dashevskyi, Jos Wetzels and Amine Amri RESEARCH REPORT | AMNESIA:33 Contents 1. Executive summary 4 2. About Project Memoria 5 3. AMNESIA:33 – a security analysis of open source TCP/IP stacks 7 3.1. Why focus on open source TCP/IP stacks? 7 3.2. Which open source stacks, exactly? 7 3.3. 33 new findings 9 4. A comparison with similar studies 14 4.1. Which components are typically flawed? 16 4.2. What are the most common vulnerability types? 17 4.3. Common anti-patterns 22 4.4. What about exploitability? 29 4.5. What is the actual danger? 32 5. Estimating the reach of AMNESIA:33 34 5.1. Where you can see AMNESIA:33 – the modern supply chain 34 5.2. The challenge – identifying and patching affected devices 36 5.3. Facing the challenge – estimating numbers 37 5.3.1. How many vendors 39 5.3.2. What device types 39 5.3.3. How many device units 40 6. An attack scenario 41 6.1. Other possible attack scenarios 44 7. Effective IoT risk mitigation 45 8. Conclusion 46 FORESCOUT RESEARCH LABS RESEARCH REPORT | AMNESIA:33 A note on vulnerability disclosure We would like to thank the CERT Coordination Center, the ICS-CERT, the German Federal Office for Information Security (BSI) and the JPCERT Coordination Center for their help in coordinating the disclosure of the AMNESIA:33 vulnerabilities.
    [Show full text]
  • DLCGI Advanced Uses
    DLCGI Advanced Uses Using DLCGI to achieve single sign-on with The Diver Solution In situations where authentication to DiveLine needs to be integrated with an existing authentication scheme, we provide "DLCGI", the DiveLine-Common Gateway Interface interfacing module. The "Common Gateway Interface" is a standard for interfacing external scripts and programs with a web server. How DLCGI works When dlcgi.exe is executed by the webserver, in the context of a user that the web server has already authenticated, it obtains a limited-lifetime one-time password from DiveLine. This password can be passed, via web page redirects, custom web page scripting, etc., to DivePort, NetDiver, or even ProDiver to allow the user to login. The typical strategy for using DLCGI is: 1. Configure DiveLine to accept DLCGI requests from your webserver. 2. Install dlcgi.exe in a scripts directory (e.g. /cgi-bin/) on your CGI-compliant webserver (e.g. IIS, Apache). You configure the name of your DiveLine server and other parameters using dlcgi.cfg in the same directory as the executable. 3. Restrict access to this script so that the webserver will only execute it when the user has already authenticated (e.g. Domain account). Typical uses • DivePort: Users go to the DivePort site, and are redirected to another URL for authentication. That URL, which runs dlcgi.exe, redirects the user back to the DivePort URL with a one-use authentication token. • ProDiver: When ProDiver connects to DiveLine, if configured with a DLCGI URL, it will access the URL in "raw" mode (see below) to obtain a parse-able result file containing a one-use DiveLine authentication token.
    [Show full text]
  • Model Driven Scheduling for Virtualized Workloads
    Model Driven Scheduling for Virtualized Workloads Proefschrift voorgelegd op 28 juni 2013 tot het behalen van de graad van Doctor in de Wetenschappen – Informatica, bij de faculteit Wetenschappen, aan de Universiteit Antwerpen. PROMOTOREN: prof. dr. Jan Broeckhove dr. Kurt Vanmechelen Sam Verboven RESEARCH GROUP COMPUTATIONAL MODELINGAND PROGRAMMING Dankwoord Het behalen van een doctoraat is een opdracht die zonder hulp onmogelijk tot een goed einde kan gebracht worden. Gelukkig heb ik de voorbije jaren de kans gekregen om samen te werken met talrijke stimulerende collega’s. Stuk voor stuk hebben zij bijgedragen tot mijn professionele en persoonlijke ontwikkeling. Hun geduldige hulp en steun was essentieel bij het overwinnen van de vele uitdagingen die met een doctoraat gepaard gaan. Graag zou ik hier dan ook enkele woorden van dank neerschrijven. Allereerst zou ik graag prof. dr. Jan Broeckhove en em. prof. dr. Frans Arickx bedanken om mij de kans te geven een gevarieerde en boeiend academisch traject te starten. Bij het beginnen van mijn doctoraat heeft Frans mij niet alleen geholpen om een capabel onderzoeker te worden, ook bij het lesgeven heeft hij mij steeds met raad en daad bijgestaan. Na het emiraat van Frans heeft Jan deze begeleiding overgenomen en er voor gezorgd dat ik het begonnen traject ook succesvol kon beeïndigen. Beiden hebben ze mij steeds grote vrijheid gegeven in mijn zoektocht om interessante onderzoeksvragen te identificeren en beantwoorden. Vervolgens zou ik graag dr. Peter Hellinckx en dr. Kurt Vanmechelen bedanken voor hun persoonlijke en vaak intensieve begeleiding. Zelfs voor de start van mijn academische carrière, bij het schrijven van mijn Master thesis, heeft Peter mij klaar- gestoomd voor een vlotte start als onderzoeker.
    [Show full text]
  • Interfacing Apache HTTP Server 2.4 with External Applications
    Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick November 6, 2012 Who am I? Interfacing Apache HTTP Server 2.4 with External Applications Met Unix (in the form of Xenix) in 1985 Jeff Trawick Joined IBM in 1990 to work on network software for mainframes Moved to a different organization in 2000 to work on Apache httpd Later spent about 4 years at Sun/Oracle Got tired of being tired of being an employee of too-huge corporation so formed my own too-small company Currently working part-time, coding on other projects, and taking classes Overview Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick Huge problem space, so simplify Perspective: \General purpose" web servers, not minimal application containers which implement HTTP \Applications:" Code that runs dynamically on the server during request processing to process input and generate output Possible web server interactions Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick Native code plugin modules (uhh, assuming server is native code) Non-native code + language interpreter inside server (Lua, Perl, etc.) Arbitrary processes on the other side of a standard wire protocol like HTTP (proxy), CGI, FastCGI, etc. (Java and \all of the above") or private protocol Some hybrid such as mod fcgid mod fcgid as example hybrid Interfacing Apache HTTP Server 2.4 with External Applications Jeff Trawick Supports applications which implement a standard wire protocol, no restriction on implementation mechanism Has extensive support for managing the application[+interpreter] processes so that the management of the application processes is well-integrated with the web server Contrast with mod proxy fcgi (pure FastCGI, no process management) or mod php (no processes/threads other than those of web server).
    [Show full text]
  • Lwip TCP/IP Stack Demonstration for Stm32f107xx Connectivity Line Microcontrollers
    AN3102 Application note lwIP TCP/IP stack demonstration for STM32F107xx connectivity line microcontrollers Introduction STM32F107xx connectivity line microcontrollers feature a high-quality 10/100 Ethernet peripheral that supports both MII and RMII to interface the PHY. One of the advanced features of the STM32F107xx's Ethernet controller is the capability of generating, inserting and verifying the checksums of the IP, UDP, TCP and ICMP protocols by hardware. In this application note, you can find a real application that uses this feature. The objective of this application note is to present a demonstration package built on top of a free TCP/IP stack: the lwIP (lightweight IP). This package contains: ● A DHCP client, for IP address setting ● A Hello example based on the Telnet protocol ● A TFTP server, which transfers files from and to the microSD™ card located on the STM3210C-EVAL board ● A web server ● A Server/Clients example, which uses multiple boards and allows clients to control the server's LEDs. November 2009 Doc ID 16620 Rev 1 1/18 www.st.com Contents AN3102 Contents 1 Porting lwIP to the STM32F107xx . 5 1.1 lwIP stack overview . 5 1.2 How to port lwIP to the STM32F107xx . 5 1.2.1 Ethernet controller interface . 5 1.2.2 Periodic lwIP tasks . 6 1.2.3 lwIP configuration . 6 1.2.4 STM32F107xx hardware checksum . 7 2 Description of the demonstration package . 8 2.1 Package directories . 8 2.2 Demonstration settings . 8 2.2.1 PHY interface configuration . 8 2.2.2 MAC address settings . 9 2.2.3 IP address settings .
    [Show full text]
  • User-Level Online Offloading Framework
    ULOOF: USER-LEVEL ONLINE OFFLOADING FRAMEWORK JOSÉ LEAL DOMINGUES NETO ULOOF: USER-LEVEL ONLINE OFFLOADING FRAMEWORK Dissertação apresentada ao Programa de Pós- -Graduação em Ciência da Computação do Instituto de Ciências Exatas da Universidade Federal de Minas Gerais como requisito par- cial para a obtenção do grau de Mestre em Ciência da Computação. ORIENTADOR:JOSÉ MARCOS S. NOGUEIRA COORIENTADOR:DANIEL F. MACEDO Belo Horizonte Março de 2016 JOSÉ LEAL DOMINGUES NETO ULOOF: USER-LEVEL ONLINE OFFLOADING FRAMEWORK Dissertation presented to the Graduate Pro- gram in Computer Science of the Federal Uni- versity of Minas Gerais in partial fulfillment of the requirements for the degree of Master in Computer Science. ADVISOR:JOSÉ MARCOS S. NOGUEIRA CO-ADVISOR:DANIEL F. MACEDO Belo Horizonte March 2016 © 2016, José Leal Domingues Neto. Todos os direitos reservados Ficha catalográfica elaborada pela Biblioteca do ICEx ­ UFMG Domingues Neto, José Leal. D671u Uloof: user­level online offloading framework. / José Leal Domingues Neto. Belo Horizonte, 2016. xxiii, 96 f.: il.; 29 cm. Dissertação (mestrado) ­ Universidade Federal de Minas Gerais – Departamento de Ciência da Computação. Orientador: José Marcos Silva Nogueira. Coorientador: Daniel Fernandes Macedo. 1. Computação – Teses. 2. Redes de computadores – Teses. 3. Computação em nuvem – Teses. I. Orientador. II. Coorientador. III. Título. CDU 519.6*22(043) Acknowledgments This work could not be completed without the support and love from many people across the world. I would like to firstly thank my mother and father. Mother, you are a true inspiration to me. Without your guidance, love and care I would not be able to glance back and cherish this joyful moment.
    [Show full text]
  • Towards Better Performance Per Watt in Virtual Environments on Asymmetric Single-ISA Multi-Core Systems
    Towards Better Performance Per Watt in Virtual Environments on Asymmetric Single-ISA Multi-core Systems Viren Kumar Alexandra Fedorova Simon Fraser University Simon Fraser University 8888 University Dr 8888 University Dr Vancouver, Canada Vancouver, Canada [email protected] [email protected] ABSTRACT performance per watt than homogeneous multicore proces- Single-ISA heterogeneous multicore architectures promise to sors. As power consumption in data centers becomes a grow- deliver plenty of cores with varying complexity, speed and ing concern [3], deploying ASISA multicore systems is an performance in the near future. Virtualization enables mul- increasingly attractive opportunity. These systems perform tiple operating systems to run concurrently as distinct, in- at their best if application workloads are assigned to het- dependent guest domains, thereby reducing core idle time erogeneous cores in consideration of their runtime proper- and maximizing throughput. This paper seeks to identify a ties [4][13][12][18][24][21]. Therefore, understanding how to heuristic that can aid in intelligently scheduling these vir- schedule data-center workloads on ASISA systems is an im- tualized workloads to maximize performance while reducing portant problem. This paper takes the first step towards power consumption. understanding the properties of data center workloads that determine how they should be scheduled on ASISA multi- We propose that the controlling domain in a Virtual Ma- core processors. Since virtual machine technology is a de chine Monitor or hypervisor is relatively insensitive to changes facto standard for data centers, we study virtual machine in core frequency, and thus scheduling it on a slower core (VM) workloads. saves power while only slightly affecting guest domain per- formance.
    [Show full text]
  • Next Generation Web Scanning Presentation
    Next generation web scanning New Zealand: A case study First presented at KIWICON III 2009 By Andrew Horton aka urbanadventurer NZ Web Recon Goal: To scan all of New Zealand's web-space to see what's there. Requirements: – Targets – Scanning – Analysis Sounds easy, right? urbanadventurer (Andrew Horton) www.morningstarsecurity.com Targets urbanadventurer (Andrew Horton) www.morningstarsecurity.com Targets What does 'NZ web-space' mean? It could mean: •Geographically within NZ regardless of the TLD •The .nz TLD hosted anywhere •All of the above For this scan it means, IPs geographically within NZ urbanadventurer (Andrew Horton) www.morningstarsecurity.com Finding Targets We need creative methods to find targets urbanadventurer (Andrew Horton) www.morningstarsecurity.com DNS Zone Transfer urbanadventurer (Andrew Horton) www.morningstarsecurity.com Find IP addresses on IRC and by resolving lots of NZ websites 58.*.*.* 60.*.*.* 65.*.*.* 91.*.*.* 110.*.*.* 111.*.*.* 113.*.*.* 114.*.*.* 115.*.*.* 116.*.*.* 117.*.*.* 118.*.*.* 119.*.*.* 120.*.*.* 121.*.*.* 122.*.*.* 123.*.*.* 124.*.*.* 125.*.*.* 130.*.*.* 131.*.*.* 132.*.*.* 138.*.*.* 139.*.*.* 143.*.*.* 144.*.*.* 146.*.*.* 150.*.*.* 153.*.*.* 156.*.*.* 161.*.*.* 162.*.*.* 163.*.*.* 165.*.*.* 166.*.*.* 167.*.*.* 192.*.*.* 198.*.*.* 202.*.*.* 203.*.*.* 210.*.*.* 218.*.*.* 219.*.*.* 222.*.*.* 729,580,500 IPs. More than we want to try. urbanadventurer (Andrew Horton) www.morningstarsecurity.com IP address blocks in the IANA IPv4 Address Space Registry Prefix Designation Date Whois Status [1] -----
    [Show full text]
  • Flask Documentation Release 0.7Dev July 14, 2014
    Flask Documentation Release 0.7dev July 14, 2014 Contents I User’s Guide1 1 Foreword3 1.1 What does “micro” mean?...........................3 1.2 A Framework and an Example........................4 1.3 Web Development is Dangerous.......................4 1.4 The Status of Python 3.............................4 2 Installation7 2.1 virtualenv....................................7 2.2 System Wide Installation...........................8 2.3 Living on the Edge...............................9 2.4 easy_install on Windows............................9 3 Quickstart 11 3.1 A Minimal Application............................ 11 3.2 Debug Mode.................................. 12 3.3 Routing..................................... 13 3.4 Static Files.................................... 17 3.5 Rendering Templates.............................. 17 3.6 Accessing Request Data............................ 19 3.7 Redirects and Errors.............................. 22 3.8 Sessions..................................... 22 3.9 Message Flashing................................ 23 3.10 Logging..................................... 24 3.11 Hooking in WSGI Middlewares....................... 24 4 Tutorial 25 4.1 Introducing Flaskr............................... 25 4.2 Step 0: Creating The Folders......................... 26 4.3 Step 1: Database Schema........................... 27 4.4 Step 2: Application Setup Code........................ 27 i 4.5 Step 3: Creating The Database........................ 29 4.6 Step 4: Request Database Connections.................... 30 4.7 Step
    [Show full text]