DOCSLIB.ORG

The Web Server With: Notice That Fastcgi Binds the Web2py Server to a Unix Socket, Not to an IP Socket

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Web Server With: Notice That Fastcgi Binds the Web2py Server to a Unix Socket, Not to an IP Socket APACHE2 AND MOD PYTHON IN A SHARED HOSTING ENVIRONMENT 295 1 nohup python fcgihandler.py & Then, (re)start the web server with: 1 /etc/init.d/lighttpd restart Notice that FastCGI binds the web2py server to a Unix socket, not to an IP socket: 1 /tmp/fcgi.sock This is where Lighttpd forwards the HTTP requests to and receives responses from. Unix sockets are lighter than Internet sockets, and this is one of the reasons Lighttpd+FastCGI+web2py is fast. As in the case of Apache, it is possible to setup Lighttpd to deal with static files directly, and to force some applications over HTTPS. Refer to the Lighttpd documentation for details. The administrative interface must be disabled when web2py runs on a shared host with FastCGI, or it will be exposed to the other users. 11.8 Apache2 and mod python in a shared hosting environment There are times, specifically on shared hosts, when one does not have the permission to configure the Apache config files directly. You can still run web2py. Here we show an example of how to set it up using mod python6 • Place contents of web2py into the "htdocs" folder. • In the web2py folder, create a file "web2py modpython.py" file with the following contents: 1 from mod_python import apache 2 import modpythonhandler 3 4 def handler(req): 5 req.subprocess_env['PATH_INFO'] = \ 6 req.subprocess_env['SCRIPT_URL'] 7 return modpythonhandler.handler(req) • Create/update the file ".htaccess" with the following contents: 1 SetHandler python-program 2 PythonHandler web2py_modpython 3 ##PythonDebug On 6Examples provided by Niktar 296 DEPLOYMENT RECIPES 11.9 Setup Cherokee with FastGGI Cherokee is a very fast web server and, like web2py, it provides an AJAX- enabled web-based interface for its configuration. Its web interface is written in Python. In addition, there is no restart required for most of the changes. Here are the steps required to setup web2py with Cherokee: • Download Cherokee [76] • Untar, build, and install: 1 tar -xzf cherokee-0.9.4.tar.gz 2 cd cherokee-0.9.4 3 ./configure --enable-fcgi && make 4 make install • Start web2py normally at least once to make sure it creates the "ap- plications" folder. • Write a shell script named "startweb2py.sh" with the following code: 1 #!/bin/bash 2 cd /var/web2py 3 python /var/web2py/fcgihandler.py & and give the script execute privileges and run it. This will start web2py under FastCGI handler. • Start Cherokee and cherokee-admin: 1 sudo nohup cherokee & 2 sudo nohup cherokee-admin & By default, cherokee-admin only listens at local interface on port 9090. This is not a problem if you have full, physical access on that machine. If this is not the case, you can force it to bind to an IP address and port by using the following options: 1 -b, --bind[=IP] 2 -p, --port=NUM or do an SSH port-forward (more secure, recommended): 1 ssh -L 9090:localhost:9090 remotehost • Open "http://localhost:9090" in your browser. If everything is ok, you will get cherokee-admin. • In cherokee-admin web interface, click "info sources". Choose "Local Interpreter". Write in the following code, then click "Add New". SETUP POSTGRESQL 297 1 Nick: web2py 2 Connection: /tmp/fcgi.sock 3 Interpreter: /var/web2py/startweb2py.sh • Click "Virtual Servers", then click "Default". • Click "Behavior", then, under that, click "default". • Choose "FastCGI" instead of "List and Send" from the list box. • At the bottom, select "web2py" as "Application Server" • Put a check in all the checkboxes (you can leave Allow-x-sendfile). If there is a warning displayed, disable and enable one of the check- boxes. (It will automatically re-submit the application server parameter. Sometimes it doesn’t, which is a bug). • Point your browser to "http://ipaddressofyoursite", and "Welcome to web2py" will appear. 11.10 Setup PostgreSQL PostgreSQL is a free and open source database which is used in demand- ing production environments, for example, to store the .org domain name database, and has been proven to scale well into hundreds of terabytes of data. It has very fast and solid transaction support, and provides an auto- vacuum feature that frees the administrator from most database maintenance tasks. On an Ubuntu or other Debian-based Linux distribution, it is easy to install PostgreSQL and its Python API with: 1 sudo apt-get -y install postgresql 2 sudo apt-get -y install python-psycopg2 It is wise to run the web server(s) and the database server on different machines. In this case, the machines running the web servers should be connected with a secure internal (physical) network, or should establish SSL tunnels to securely connect with the database server. Start the database server with: 1 sudo /etc/init.d/postgresql restart When restarting the PostgreSQL server, it should notify which port it is running on. Unless you have multiple database servers, it should be 5432. The PostgreSQL configuration file is: 298 DEPLOYMENT RECIPES 1 /etc/postgresql/x.x/main/postgresql.conf (where x.x is the version number). The PostgreSQL logs are in: 1 /var/log/postgresql/ Once the database server is up and running, create a user and a database so that web2py applications can use it: 1 sudo -u postgres createuser -P -s myuser 2 createdb mydb 3 echo 'The following databases have been created:' 4 psql -l 5 psql mydb The first of the commands will grant superuser-access to the new user, called myuser. It will prompt you for a password. Any web2py application can connect to this database with the command: 1 db = DAL("postgres://myuser:mypassword@localhost:5432/mydb") where mypassword is the password you entered when prompted, and 5432 is the port where the database server is running. Normally you use one databasefor eachapplication, and multiple instances of the same application connect to the same database. It is also possible for different applications to share the same database. For database backup details, read the PostgreSQL documentation; specifi- cally the commands pg dump and pg restore. 11.11 Security Issues It is very dangerous to publicly expose the admin application and the ap- padmin controllers unless they run over HTTPS. Moreover, your password and credentials should never be transmitted unencrypted. This is true for web2py and any other web application. In your applications, if they require authentication, you should make the session cookies secure with: 1 session.secure() An easy way to setup a secure production environment on a server is to first stop web2py and then remove all the parameters *.py files from the web2py installation folder. Then start web2py without a password. This will completely disable admin and appadmin. Next, start a second Python instance accessible only from localhost: 1 nohup python web2py -p 8001 -i 127.0.0.1 -a '<ask>' & SCALABILITY ISSUES 299 and create an SSH tunnel from the local machine (the one from which you wish to access the administrative interface) to the server (the one where web2py is running, example.com), using: 1 ssh -L 8001:127.0.0.1:8001 [email protected] Now you can access the administrative interface locally via the web browser at localhost:8001. This configuration is secure because admin is not reachable when the tunnel is closed (the user is logged out). This solution is secure on shared hosts if and only if other users do not have read access to the folder that contains web2py; otherwise users may be able to steal session cookies directly from the server. 11.12 Scalability Issues web2py is designed to be easy to deploy and to setup. This does not mean that it compromises on efficiency or scalability, but it means you may need to tweak it to make it scalable. In this section we assume multiple web2py installations behind a NAT server that provides local load-balancing. In this case, web2py works out-of-the-box if some conditions are met. In particular, all instances of each web2py application must access the same database server and must see the same files. This latter condition can be implemented by making the following folders shared: 1 applications/myapp/sessions 2 applications/myapp/errors 3 applications/myapp/uploads 4 applications/myapp/cache The shared folders must support file locking. Possible solutions are ZFS7, NFS8, or Samba (SMB). It is possible, but not a good idea, to share the entire web2py folder or the entire applications folder, because this would cause a needless increase of network bandwidth usage. We believe the configuration discussed above to be very scalable because it reduces the databaseload by moving to the shared filesystems those resources 7ZFS was developed by Sun Microsystems and is the preferred choice. 8With NFS you may need to run the nlockmgr daemon to allow file locking. 300 DEPLOYMENT RECIPES that need to be shared but do not need transactional safety (only one client at a time is supposed to access a session file, cache always needs a global lock, uploads and errors are write once/read many files). Ideally, both the database and the shared storage should have RAID capa- bility. Do not make the mistake of storing the database on the same storage as the shared folders, or you will create a new bottle neck there. On a case-by-casebasis, you may needto perform additionaloptimizations and we will discuss them below. In particular, we will discuss how to get rid of these shared folders one-by-one, and how to store the associated data in the database instead. While this is possible, it is not necessarily a good solution. Nevertheless, there may be reasons to do so.
Load more

Recommended publications
  • 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]
  • GNU/Linux Magazine Hors-Série N°66 Apache Introduction
    LES GUIDES DE sur les origines d Ce documntslapriéxvj-g(@h.)26013à:5 Tout ce qu LE GUIDE COMPLET POUR METTRE EN PLACE ET BIEN CONFIGURER VOTRE SERVEUR WEB APACH France METRO : 12.90 et sur ses principales Introduction fonctionnalités il faut savoir Apache CH : 18,00 CHF Installation et con Installer son premier BEL/PORT.CONT : 13,90 serveur et choisir le mécanisme d plus adapté authenti HORS-SÉRIE guration ���� cation le DOM TOM : 13,90 Programmer pour le Web PHP, Python, Perl et Ruby : quelques bases pour bien programmer avec les langages du Web CAN : 18,00 $ cad Aller plus loin MAR : 130 MAD Des éléments de con pour des besoins plus spéci (LDAP, chi guration avancée ques L 15066 ff Édité par Les Éditions Diamond Éditions Les par Édité rement, ...) www.ed-diamond.com -66H F: Tutoriels Des pas-à-pas 12,90 pour passer E rapidement à la pratique € -RD Ce documntslapriéxvj-g(@h.)26013à:5 2 GNU/LiNUx maGaziNeHors-série N°66 : apacHe Impression : Service abonnement: Responsable publicité: Conception graphique: Remerciements Secrétaire derédaction Rédacteur enchef: Directeur depublication: Sites : Service commercial: E-mail : Tél. : est éditépar GNU/Linux MagazineHors-Série Éditions Diamond. rédigés parlesmembresdel'équiperédactionnelledes Les articlesnonsignéscontenusdanscenuméroontété respectif. droit ayant leur de propriété sont la dans le magazine les représentés logos Tous respectif. citées dans ce numéro sont déposées par les sans aucun marques Toutes d’information, but publicitaire. leur propriétaire figurant dans d’adresses les et prix pages de sont rédactionnelles indications données Les à renvoyés. titre ni rendus, ni sont GNU/Linux Magazine France Hors-série, publiés ou non, ne particulier, les manuscrits, photos accord écrit et de la société Les éditions Diamond.
    [Show full text]
  • X-Switch: an Efficient, Multi-User, Multi-Language Web Ap- Plication Server
    Research Article | SACJ, Submission, 2009 1 X-Switch: An Efficient, Multi-User, Multi-Language Web Ap- plication Server Mayumbo Nyirenda, Hussein Suleman, Andrew Maunder, Reinhardt van Rooyen Department of Computer Science, University of Cape Town ABSTRACT Web applications are usually installed on and accessed through a Web server. For security reasons, these Web servers generally provide very few privileges to Web applications, defaulting to executing them in the realm of a guest account. In addition, performance often is a problem as Web applications may need to be reinitialised with each access. Various solutions have been designed to address these security and performance issues, mostly independently of one another, but most have been language or system-specific. The X-Switch system is proposed as an alternative Web application execution environment, with more secure user-based resource management, persistent application interpreters and support for arbitrary languages/interpreters. Thus it provides a general-purpose environment for developing and deploying Web applications. The X-Switch system's experimental results demonstrated that it can achieve a high level of performance. Furthermore it was shown that X-Switch can provide functionality matching that of existing Web application servers but with the added benefit of multi-user support. Finally the X-Switch system showed that it is feasible to completely separate the deployment platform from the application code, thus ensuring that the developer does not need to modify his/her code to make it compatible with the deployment platform. KEYWORDS: Web application servers, scalability, context switching, process persistence, modularity 1 INTRODUCTION in Java, another in PHP and a third in Perl, it is non-trivial (if at all possible) to have a single Web Web applications that once were fairly monolithic are server software system cater for all languages and, ad- slowly making the transition to collections of cooper- ditionally, keep all interpreters and virtual machines ating services.
    [Show full text]
  • Fastcgi 1 Fastcgi
    FastCGI 1 FastCGI FastCGI es un protocolo para interconectar programas interactivos con un servidor web. FastCGI es una variación de la ya conocida Common Gateway Interface (CGI ó Interfaz Común de Entrada). El principal objetivo de FastCGI es reducir la carga asociada con el hecho de interconectar el servidor web y los programas Common Gateway Interface, permitiéndole a un servidor atender más peticiones a la vez. Ventajas • Independencia del lenguaje utilizado. Libertad de elección de la plataforma de desarrollo: C++, PHP, Perl, Java, entre otros. • Se utiliza un proceso separado. Libertad de elección del servidor web. Facilidad para el tratamiento de errores y depuración. • Es posible la ejecución en host separado. Mayor libertad para configuración del sistema, tanto en el diseño de la red como en la elección de los sistemas operativos. Disminución de la carga de trabajo del servidor principal. En resumen, la libertad de diseño de CGI a la velocidad de un módulo del servidor.. Historia CGI es un protocolo para interconectar aplicaciones externas con servidores web. Las aplicaciones CGI corren en un proceso separado que es creado al inicio de cada petición y es finalizado cuando termina su trabajo. Este modelo de "un nuevo proceso por cada petición" hace que los programas CGI sean muy fáciles de implementar, pero limita la eficiencia y la escalabilidad. En altas cargas, la sobrecarga en el sistema operativo por la creación y destrucción de procesos se torna significativa y limita la escalabilidad. Además, el modelo de procesos CGI limita las técnicas de reutilización de recursos (como ser la reutilización de conexiones a base de datos, caché en memoria, etc).
    [Show full text]
  • Red Hat Enterprise Linux 7 7.8 Release Notes
    Red Hat Enterprise Linux 7 7.8 Release Notes Release Notes for Red Hat Enterprise Linux 7.8 Last Updated: 2021-03-02 Red Hat Enterprise Linux 7 7.8 Release Notes Release Notes for Red Hat Enterprise Linux 7.8 Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]
  • Internet Based Robot Control Using CORBA Based Communications a Study Into the Simplification of Multirobot Control
    Defence Research and Recherche et développement Development Canada pour la défense Canada Internet Based Robot Control Using CORBA Based Communications A study into the simplification of multirobot control S. Verret and J. Collier DRDC Suffield A. von Bertoldi ADGA Inc. Defence R&D Canada Technical Memorandum DRDC Suffield TM 2009-127 December 2009 Internet Based Robot Control Using CORBA Based Communications A study into the simplification of multirobot control S. Verret and J. Collier Defence R&D Canada – Suffield A. von Bertoldi ADGA Inc. 125 Taravista Way NE Calgary, Alberta T3J 4K8 Defence R&D Canada – Suffield Technical Memorandum DRDC Suffield TM 2009-127 December 2009 Principal Author Original signed by S. Verret S. Verret Approved by Original signed by D.M. Hanna D.M. Hanna Head/AISS Approved for release by Original signed by Dr P.A. D’Agostino Dr P.A. D’Agostino Head/Document Review Panel © Her Majesty the Queen in Right of Canada as represented by the Minister of National Defence, 2009 © Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2009 Abstract Researchers in the field of robotics have been seeking methods to both control and monitor their vehicles. Unfortunately the programs they have developed to perform these tasks are normally dependent on the robotic software infrastructure or are very difficult to understand for an outside user. This paper looks to tackle the problem of monitoring and controlling a robotics system using a web browser. The goal of this paper is to describe the potential for a system that will control and monitor a CORBA based robotics framework from a simple HTTP based browser.
    [Show full text]
  • Ach Walkthrough: Designing and Building a Web Application for Collaborative Sensemaking
    ACH WALKTHROUGH: DESIGNING AND BUILDING A WEB APPLICATION FOR COLLABORATIVE SENSEMAKING by Robert Jeffrey Pardoe Wilson A thesis submitted to the Faculty of Graduate Studies and Postdoctoral Affairs in partial fulfillment of the requirements for the degree of MASTER OF COMPUTER SCIENCE School of Computer Science at CARLETON UNIVERSITY Ottawa, Ontario September, 2015 © Copyright by Robert Jeffrey Pardoe Wilson, 2015 Contents List of Figures v Abstract vii Acknowledgements viii Chapter 1 Introduction 1 1.1 Motivation . .1 1.2 Organization of this thesis . .3 1.3 Contributions . .4 1.4 Publications . .4 Chapter 2 Background on Sensemaking 7 2.1 Introduction . .7 2.2 The Cost Structure of Sensemaking . .8 2.3 The Sensemaking Process . 12 2.4 Space to Think . 16 2.5 Summary . 19 Chapter 3 Background on Surface Application Development 20 3.1 Application development processes . 20 3.1.1 Designing for visual analysis . 20 3.1.2 Designing for rapidly evolving requirements . 21 3.1.3 Usability analysis techniques . 23 3.2 Application development frameworks . 25 3.2.1 Features of multi-touch development frameworks . 26 3.2.2 OS-specific frameworks . 29 3.2.3 Python-based frameworks . 30 3.2.4 Java-based frameworks . 32 ii 3.2.5 Web-based frameworks . 33 3.2.6 Choosing a framework . 35 3.3 Issues arising . 36 Chapter 4 Architecture 39 4.1 TUIO Host . 39 4.2 Proof of Concept . 41 4.3 Revised Architecture . 42 4.4 Architectural Rationale . 43 4.4.1 Data Flows and Distributed UI . 45 4.4.2 Data-Driven Visualizations .
    [Show full text]
  • N1ql: a Practical Guide N1ql = Sql + Json
    N1QL: A PRACTICAL GUIDE N1QL = SQL + JSON Gerald Sangudi Sitaram Vemulapalli Marco Greco Johan Larson Isha Kandaswamy Prasad Varakur Eben Haber Manuel Hurtado Keshav Murthy Tai Tran Foreword by Gerald Sangudi, father of N1QL To Couchbase & N1QL Customers & Community Foreword We are excited to present this eBook to you, our N1QL customers, users and readers. We started developing N1QL way back in 2013, when we realized that people were managing more of their data in JSON, but in doing so, they were having to give up the benefits of SQL querying. We appreciate both SQL and JSON, and we thought users should have the benefits of both. After a few developer previews and much helpful feedback from early users and customers, N1QL was released in 2015. As of this writing in March 2017, N1QL is being used by over 100 enterprise customers, and many times that number of community users and developers. N1QL has steadily grown in sophistication, functionality, and performance. This book is a compilation of some of our DZone articles through 2016. We have found DZone to be a great medium for N1QL blogs and articles. In addition to the initial reading, the articles serve as a continuous resource for questions, learning, reference, and discussion. A special thanks to our Couchbase and community colleagues, including those who contributed articles after 2016. We hope you enjoy this eBook. If you have feedback or suggestions for future topics, please share them on our forums, on Stack Overflow, and of course, on DZone. Gerald Sangudi For Team N1QL Mountain View, California th March, 14 ,​ 2017 ​ Enterprise Jobs To Be DONE Enterprises on Getting the Jobs Done Authors: Gerald Sangudi, Keshav Murthy ​ Every enterprise, from the biggest and most familiar brand to the up and coming innovator, has important jobs to get done.
    [Show full text]
  • Apache2 Web Server
    « Alien – Convert RPM to DEB or DEB to RPM Linux and Ubuntu Counter – Register your Linux and your Ubuntu » Apache2 Web server January 24, 2008 by taufanlubis What is Web Server? Before we go to that question, it’s better if we know what is web. Actually, web is only a file or document in HTML format which is transferred from 1 computer (server) to a computer (client) which requests that file/document. To read a web document you need a web client application. There are so many web client applications available, such as Mozilla, Firefox, Opera etc. Did you get a picture what is the Web Server? Yes, Web Server is an application in a computer that supplies files or document which are requested by client computer. There are few web server available in market, such as Apache, IIS and Cold Fusion, but the most popular web server in the world is Apache. Because, almost 70% web servers in the world use Apache. Apache is under GPL. So, you can use it for free. Apache2 or Apache Web Server a default web server installed in Ubuntu. Note: If you are using Gutsy, you don’t have to do the installation. You have it already. You just need to configure the setting only. If you want to use PHP4, you can’t use apache2, it’s designed to work with PHP5 now. You can use Xampp. With Xampp, even you can choose which PHP version that you want to use, PHP4 or PHP5, without change any configuration. Step 1. Apache Installation To install Apache2 in Ubuntu, just type the command below in your Terminal Console.
    [Show full text]
  • Interactive Computer Vision Through the Web
    En vue de l'obtention du DOCTORAT DE L'UNIVERSITÉ DE TOULOUSE Délivré par : Institut National Polytechnique de Toulouse (Toulouse INP) Discipline ou spécialité : Informatique et Télécommunication Présentée et soutenue par : M. MATTHIEU PIZENBERG le vendredi 28 février 2020 Titre : Interactive Computer Vision through the Web Ecole doctorale : Mathématiques, Informatique, Télécommunications de Toulouse (MITT) Unité de recherche : Institut de Recherche en Informatique de Toulouse ( IRIT) Directeur(s) de Thèse : M. VINCENT CHARVILLAT M. AXEL CARLIER Rapporteurs : M. MATHIAS LUX, ALPEN ADRIA UNIVERSITAT Mme VERONIQUE EGLIN, INSA LYON Membre(s) du jury : Mme GÉRALDINE MORIN, TOULOUSE INP, Président M. AXEL CARLIER, TOULOUSE INP, Membre M. CHRISTOPHE DEHAIS, ENTREPRISE FITTINGBOX, Membre M. OGE MARQUES, FLORIDA ATLANTIC UNIVERSITY, Membre M. VINCENT CHARVILLAT, TOULOUSE INP, Membre ii Acknowledgments First I’d like to thank my advisors Vincent and Axel without whom that PhD would not have been possible. I would also like to thank Véronique and Mathias for reviewing this manuscript, as well as the other members of the jury, Oge, Géraldine and Christophe for your attention, remarks and interesting discussions during the defense. Again, a special thank you Axel for all that you’ve done, throughout this long period and even before it started. I haven’t been on the easiest path toward completion of this PhD but you’ve always been there to help me continue being motivated and that’s what mattered most! Wanting to begin a PhD certainly isn’t a one-time moment, but for me, the feeling probably started during my M1 internship. I was working in the VORTEX research team (now REVA) on a project with Yvain and Jean-Denis and it was great! Yet “I don’t think so” was more or less what I kept answering to my teachers when they would ask if I wished to start a PhD at that time.
    [Show full text]
  • Survey of Technologies for Web Application Development
    Survey of Technologies for Web Application Development BARRY DOYLE University of California, Irvine and CRISTINA VIDEIRA LOPES University of California, Irvine Web-based application developers face a dizzying array of platforms, languages, frameworks and technical artifacts to choose from. We survey, classify, and compare technologies supporting Web application development. The classification is based on (1) foundational technologies; (2) integration with other information sources; and (3) dynamic content generation. We further survey and classify software engineering techniques and tools that have been adopted from traditional programming into Web programming. We conclude that, although the infrastructure problems of the Web have largely been solved, the cacophony of technologies for Web-based applications reflects the lack of a solid model tailored for this domain. Categories and Subject Descriptors: A.1 [General Literature]: Introductory and Survey; D.1.0 [Programming Techniques]: General; D.1.1 [Programming Techniques]: Object-oriented Programming; D.2.11 [Software Engineering]: Software Architectures—languages; patterns; H.3.5 [Information Storage and Retrieval]: Online Information Systems—data sharing; Web- based services; H.5.4 [Hypertext/Hypermedia]: Architectures General Terms: Design, Programming, Languages Additional Key Words and Phrases: Web applications, Web programming, scripting languages 1. THE DEMAND FOR DYNAMIC CONTENT Within a decade of its inception, the Web evolved from a static hypertext pre- sentation medium into a standard user interface technology for a growing class of interactive information systems. The initial Web implementation, defined by its static nature and a purposefully low barrier to entry, was sufficient for sharing doc- uments but inadequate for more advanced applications. The early Web, despite Author’s addresses: B.
    [Show full text]
  • Modprotect T1 Extunderscore Python Documentation
    Mod_python Documentation Release 3.5.0-3.5.0 Gregory Trubetskoy November 13, 2013 CONTENTS 1 Introduction 3 1.1 Performance...............................................3 1.2 Apache HTTP Server API........................................3 1.3 Other Features..............................................3 2 Installation 5 2.1 Prerequisites...............................................5 2.2 Compiling................................................5 2.3 Installing.................................................6 2.4 Configuring Apache...........................................7 2.5 Testing..................................................7 2.6 Troubleshooting.............................................8 3 Tutorial 9 3.1 A Quick Start with the Publisher Handler................................9 3.2 Quick Overview of how Apache Handles Requests........................... 11 3.3 So what Exactly does Mod-python do?................................. 11 3.4 Now something More Complicated - Authentication.......................... 13 3.5 Your Own 404 Handler.......................................... 14 4 Python API 17 4.1 Multiple Interpreters........................................... 17 4.2 Overview of a Request Handler..................................... 18 4.3 Overview of a Filter Handler....................................... 19 4.4 Overview of a Connection Handler................................... 20 4.5 apache – Access to Apache Internals.................................. 20 4.6 util – Miscellaneous Utilities....................................
    [Show full text]