MVCGI: Modelo de Implementación Estándar para ... · MVCGI: Modelo de Implementación Estándar...

MVCGI: Modelo de Implementación Estándar

para arquitecturas MVC modulares en

programas de interfaz CGI

Eugenia Bahit

Diciembre 2016

Resumen

Este documento pretende sentar precedente para discutir las bases de

un método (o modelo) de diseño estándar (al que a los �nes prácticos

se menciona en el presente como �MVCGI�) para la implementación de

arquitecturas MVC modulares en programas CGI. Esta primera versión

se concentra -mayormente- en cuestiones relativas a la seguridad de la

aplicación y a su arquitectura, siendo todo lo aquí mencionado, válido para

cualquier lenguaje de programación interpretado de alto nivel, incluyendo

-pero no limitándose a- Python, PHP, Ruby y Perl, entre otros.

© 2016 Eugenia Bahit. Laboratorio de Altos Estudios en Ciencias In-

formáticas (LAECI). Se otorga permiso para copiar, distribuir y/o modi-

�car este documento bajo los términos de la Licencia de Documentación

Libre de GNU, Versión 1.3 o cualquier otra versión posterior publicada

por la Free Software Foundation. Una copia de la licencia está incluida en

la sección titulada �GNU Free Documentation License�.

1

MVCGI 1.0.6 Diciembre 2016

Índice

I Introducción 4

1. Destinatarios 5

2. Requisitos previos 5

II Modelo propuesto. Método. 6

3. Sistema de Archivos 6

3.1. Componentes del sistema de archivos . . . . . . . . . . . . . 7

3.2. Árbol de directorios . . . . . . . . . . . . . . . . . . . . . . 8

3.3. Sistema de permisos . . . . . . . . . . . . . . . . . . . . . . 8

4. Con�guración del Host Virtual de Apache 8

4.1. Con�guración del servidor HTTP . . . . . . . . . . . . . . . 8

4.1.1. Consideraciones generales sobre el rendimiento . . . 8

4.1.2. Consideraciones particulares sobre la seguridad . . . 9

4.1.3. Modelo de con�guración para el VirtualHost . . . . 9

4.2. Consideraciones particulares sobre la interacción de la

interfaz CGI con otros módulos . . . . . . . . . . . . . . . . 10

4.2.1. Pruebas realizadas con PHP como CGI simultánea-

mente con el módulo php5 . . . . . . . . . . . . . . . 10

4.2.2. Valoración de resultados . . . . . . . . . . . . . . . . 12

4.3. Consideraciones particulares sobre los archivos de con�gu-

ración general y distribuido (httpd.conf y .htaccess) . . . . . 12

5. Política de nombres para módulos, modelos, vistas y

controladores 13

5.1. Política de nombres . . . . . . . . . . . . . . . . . . . . . . . 13

5.2. Formato de la URI . . . . . . . . . . . . . . . . . . . . . . . 13

6. Archivo de control frontal ejecutable (eXecutable Front

Controller - XFC-) 14

6.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.2. Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . 14

6.3. Características . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.4. Llamada al controlador solicitado . . . . . . . . . . . . . . . 15

6.4.1. Saneamiento . . . . . . . . . . . . . . . . . . . . . . 15

6.4.2. Validación de la solicitud . . . . . . . . . . . . . . . 15

6.5. Manejo de solicitudes erróneas . . . . . . . . . . . . . . . . 15

6.5.1. Cuestiones de seguridad en la modi�cación del

código de estado . . . . . . . . . . . . . . . . . . . . 16

© 2016 Eugenia Bahit 2 Licencia GNU FDL


6.6. Modi�cación de los códigos de respuesta del servidor HTTP 16

6.7. Código de ejemplo de un XFC en Python . . . . . . . . . . 17

7. Archivo de inicialización de variables de entorno de la

aplicación 18

7.1. Responsabilidad del archivo de inicialización de variables . . 18

7.2. Variables de entorno . . . . . . . . . . . . . . . . . . . . . . 18

7.3. Cuestiones de seguridad relativas a la inicialización de las

variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8. Archivo de con�guración 20

8.1. Variables de con�guración sugeridas . . . . . . . . . . . . . 21

9. Consideraciones generales sobre los encabezados del

servidor HTTP/1.1 21

9.1. Aviso legal sobre la sección . . . . . . . . . . . . . . . . . . 21

9.2. Recomendaciones para la modi�cación de encabezados

según las RFC . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.3. Línea de inicio . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.4. Campos de encabezado . . . . . . . . . . . . . . . . . . . . . 23

9.5. Fuentes de documentación originales . . . . . . . . . . . . . 23

10.Correspondencia 23

III GNU Free Documentation License 24

1. APPLICABILITY AND DEFINITIONS 25

2. VERBATIM COPYING 27

3. COPYING IN QUANTITY 27

4. MODIFICATIONS 28

5. COMBINING DOCUMENTS 30

6. COLLECTIONS OF DOCUMENTS 30

7. AGGREGATION WITH INDEPENDENT WORKS 31

8. TRANSLATION 31

9. TERMINATION 31

10. FUTURE REVISIONS OF THIS LICENSE 32

11. RELICENSING 32



Parte I

Introducción

CGI (Common Gateway Interfaz) es de�nido en la RFC38751 como una interfaz

sencilla para ejecutar programas bajo servidores HTTP de forma independiente

a la plataforma (Robinson & Coard, 2004), proponiendo un mecanismo de

comunicación entre la aplicación y el servidor que facilita la independencia de

ambos.

Por su parte, MVC es un patrón arquitectónico, originalmente de�nido como un

�lenguaje de patrones� (Reenskaug, 1979) y posteriormente como �paradigma

de programación� (Krasner & Pope, 1988), que propone una independencia

similar entre la abstracción de los datos de un sistema y las diferentes

representaciones grá�cas de éstos (Reenskaug, 1979).

La independencia que plantea la implementación simultánea de CGI como

interfaz de comunicación entre la aplicación y el servidor, por un lado, y, MVC

como método de comunicación interno de los componentes abstractos de un

programa y su interfaz grá�ca de usuario (GUI), por el otro, podrían suponer

la posibilidad de crear herramientas de bajo coste para el servidor (debido a la

escasez de recursos que requieren ser consumidos) y de gran portabilidad (como

consecuencia directa de la falta de dependencia).

En los años posteriores a la presentación de los modelos ut supra mencionados

(e incluso en la actualidad) se han presentado un gran número de herramientas

destinadas al desarrollo de sistemas informáticos y de a poco, la interfaz CGI

ha ido quedando en desuso y con ella, las investigaciones sobre la seguridad

en programas que implementen dicha interfaz. Por otra parte, el scripting

involucrado en la escritura de programas CGI, no ha sido incluido hasta la

actualidad, como parte de los estudios de investigación sobre buenas prácticas

de programación y estructuras de código limpio, siendo ambas problemáticas,

seguridad y falta de estudio de las buenas prácticas en el scripting, dos

posibles impedimentos para considerar viable el diseño de programas CGI

que implementen arquitecturas MVC modulares, seguras, portables, livianas

y legibles.

A �n de erradicar ambas problemáticas y ofrecer entonces, una alternativa

viable, a continuación, se expone una propuesta de modelización para la

implementación de arquitecturas MVC modulares en programas CGI, abriendo

las bases necesarias para discutir un modelo estandarizado a futuro.



1. Destinatarios

Desarrolladores de frameworks

Ingenieros del núcleo

2. Requisitos previos

Para un entendimiento e�caz del presente documento, se recomienda:

1) Poseer o adquirir un dominio avanzado de con�guración del

servidor HTTP de Apache, sobre sistemas GNU/Linux.

Para tener una aproximación a este dominio, se recomienda leer la docu-

mentación o�cial de Apache sobre Seguridad y generación de contenido dinámico

con CGI: http://httpd.apache.org/docs/current/.

Un acercamiento rápido y super�cial a la con�guración de Apache para la

ejecución de programas CGI, puede obtenerse con la Guía �Dynamic Content

with CGI� de Apache: https://httpd.apache.org/docs/current/howto/cgi.html

Para un acercamiento más exhaustivo se recomienda la lectura de los siguientes

documentos (ver las direcciones URL de referencia en las notas �nales):

Apache Performance Tuning2

Security Tips3

Apache Virtual Host Documentation4

Apache mod_rewrite5

Apache HTTP Server tutorial: .htaccess �le6

AllowOverride directive7

2) Estar familiarizado o familiarizarse con el diseño de arquitecturas

MVC propuesto por Trygve Reenskaug en 1979.

Para una aproximación a este conocimiento, se recomienda leer la docu-

mentación original de MVC en el Sitio Web del autor, Trygve M. H. Reenskaug:



http://heim.i�.uio.no/~trygver/

3) Estar familiarizado o familiarizarse con la lectura y el estudio de

las RFC publicadas por la Internet Engineering Task Force (IETF).

Para tener una aproximación a las RFC, se recomienda la lectura de las RFC3875

(The Common Gateway Interface [CGI] Version 1.1) y RFC7230-5 (Hypertext

Transfer Protocol [HTTP/1.1]).

4) Poseer o adquirir un dominio intermedio de notación simbólica en

lenguaje formal (lógica simbólica o matemática).

Para tener una aproximación a la lógica simbólica y al lenguaje formal, se

recomienda la lectura de los apuntes de la cátedra de Introducción a la Lógica y

Métodos Cientí�cos, del PEA de LAECI (http://46.101.4.154/PEA/COD3/).

5) Estar familiarizado o familiarizarse con la notación BNF

(Backus�Naur form).

Para tener una aproximación a la notación BNF extendida, se recomienda una

lectura rápida y super�cial de la ISO/IEC 14977/1996:

https://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf

Parte II

Modelo propuesto. Método.

3. Sistema de Archivos

Se destina:

1. un directorio raíz como entrada principal al sistema;

2. un directorio de aplicación, manejado por un archivo de control frontal

ejecutable (executable front controller -XFC-) y,

3. un directorio estático de libre acceso.

Estos tres directorios representan la base para el sistema de archivos y son

explicados en lo sucesivo.



3.1. Componentes del sistema de archivos

Directorio raíz del sistema:

Destinado a nuclear los archivos estáticos y de la aplicación.

Directorio de aplicación

Destinado a nuclear los archivos fuente de la aplicación y

mantenerlos separados del contenido estático.

Núcleo del sistema

Directorio destinado a nuclear los archivos centrales de la aplicación,

comunes a cualquier sistema.

Módulos del sistema

Directorio destinado al almacenaje de archivos de funcionalidades

especí�ca de la aplicación.

Archivo de control frontal ejecutable (eXecutable Front Controller - XFC)

Manejador general de solicitudes HTTP de la aplicación.

Archivo de inicialización de variables de entorno de la aplicación

Meta-variables (o variables de entorno) de la aplicación, necesarias

para su funcionamiento pero no con�gurables.

Archivo de con�guración

Variables de con�guración especí�ca de la aplicación.

Directorio estático

Destinado a nuclear archivos estáticos y binarios no ejecutables.



3.2. Árbol de directorios

rootsystem/

application /

core /

modules/

config.py|php|rb|pl|sh|<other>

xfc.py|php|rb|pl|sh|<other>

settings.py|php|rb|pl|sh|<other>

static

3.3. Sistema de permisos

Se asignan permisos 755 a directorios y 644 a archivos. Se habilitan permisos de

ejecución en el controlador frontal (XFC) de la aplicación.

rootsystem/

[drwxr-xr-x] application /

[drwxr-xr-x] core /

[drwxr-xr-x] modules/

[-rw-r--r--] config.py|php|rb|pl|sh|<other>

[-rwxr-xr-x] xfc.py|php|rb|pl|sh|<other>

[-rw-r--r--] settings.py|php|rb|pl|sh|<other>

[drwxr-xr-x] static /

4. Con�guración del Host Virtual de Apache

4.1. Con�guración del servidor HTTP

4.1.1. Consideraciones generales sobre el rendimiento

Todas las variables de con�guración son manejadas a través de sus correspon-

dientes directivas en un archivo de con�ración de host virtual (VirtualHost) del

servidor HTTP de Apache. Se evita el empleo de un archivo de con�guración

distribuido, .htaccess (se recomienda la lectura de la sección 4.3 en la página 12

para una explicación detallada). Se evita la modi�cación directa del archivo de

con�guración de Apache (httpd.conf o su equivalente según distribución) por los

motivos expuestos en la sección 4.3.



4.1.2. Consideraciones particulares sobre la seguridad

1. Se establece como DocumentRoot el directorio raíz del sistema a �n de

habilitar una única vía de acceso a la aplicación.

2. Se prohíbe la indexación de todos los directorios a �n de evitar la

exposición del sistema de archivos de la aplicación.

3. Se redirigen todas las solicitudes realizadas sobre el directorio raíz, al XFC

a �n de mantener un control absoluto sobre la totalidad de peticiones

(incluyendo las solicitudes erróneas) desde un único archivo de control

frontal.

4. Se exceptúan las peticiones al directorio estático del control frontal de

solicitudes, a �n de que las mismas sean manejadas únicamente por el

servidor HTTP de Apache.

5. Se deshabilita la reescritura de la URL en cada uno de los directorios, a

�n de evitar la sobrecarga del servidor (ver sección 4.3 en la página 12

para una descripción especí�ca).

6. Se establece un manejador de scripts CGI a nivel del directorio de la

aplicación. Se evita la habilitación del mismo a nivel del XFC como

medida de seguridad preventiva y complementaria en el supuesto de que

una vulnerabilidad en la seguridad del XFC permitiese el acceso a otros

scripts del sistema. En dicho supuesto, la falta de permisos de ejecución

en los scripts causaría un error en la solicitud recibida por el servidor

HTTP de Apache, generando un código de respuesta HTTP/1.1 500

Internal Server Error. En el supuesto de una vulnerabilidad en el XFC, el

establecimiento de un manejador de scripts CGI solo a nivel del mismo,

facilitaría la descarga del código fuente de los scripts no alcanzados por

dicho manejador. Frente al supuesto escenario, se pondera el fallo del

servidor HTTP de Apache por sobre la exposición del código fuente.

4.1.3. Modelo de con�guración para el VirtualHost

Se utiliza la siguiente plantilla como base para la creación del archivo de

con�guración del VirtualHost empleado por el servidor HTTP de Apache para

el manejo del dominio a nivel de la aplicación:

ServerName <hostname>



DocumentRoot /<path>/<project>/<root>

ErrorLog /<path>/<project>/logs/error.log

CustomLog /<path>/<project>/logs/access.log combined

<Directory "/<path>/<project>/<root>">

Options -Indexes

AllowOverride None

RewriteEngine On

RewriteRule !(^static) application/xfc.py

</Directory>

<Directory "/<path>/<project>/<root>/application">

Options +ExecCGI -Indexes

<FilesMatch "\.<extension>$">

# Ver justificación en sección 4.2

SetHandler cgi-script

</FilesMatch>

AllowOverride None

</Directory>

<Directory "/<path>/<project>/<root>/static">

Options -Indexes

AllowOverride None

</Directory>

Donde:

<extension> = py|php|rb|pl|<other>

(Ver justi�cación del uso de FilesMatch en sección 4.2)

4.2. Consideraciones particulares sobre la interacción de

la interfaz CGI con otros módulos

4.2.1. Pruebas realizadas con PHP como CGI simultáneamente con

el módulo php5

Las pruebas realizadas para ejecutar programas PHP con interfaz CGI de forma

concomitante con el módulo php5 habilitado en Apache 2.2 sobre Debian 7.11,



arrojaron los siguientes resultados:

PRUEBA 1.A) Sin el empleo de FilesMatch para inicializar el manejador

CGI en el VirtualHost, resultaron en una respuesta prematura del módulo

php5 sobre la interfaz CGI (ver Algoritmo 1).

Algoritmo 1 Habilitación del manejador CGI sin captura de la extensión delarchivo del XFC

<Directory "/<root_path>/application">



AllowOverride None

</Directory>

PRUEBA 1.B) Sin modi�caciones al VirtualHost, la deshabilitación

del módulo php5 permitió al intérprete responder de forma normal a las

solicitudes del programa CGI.

PRUEBA 1.C) La implementación de las instrucciones RemoveHandler

.php y RemoveLanguage .php de forma individual y simultánea, en el

directorio raíz, en el directorio de la aplicación y en ambos a la vez, no

modi�caron los resultados.

PRUEBA 1.D) La modi�cación de la extensión del XFC por una

diferente a .php priorizó la actuación de la interfaz CGI sobre la del módulo

php5.

PRUEBA 1.E) La habilitación del manejador de la interfaz CGI

mediante la captura de la extensión .php respondió de la misma forma

que la modi�cación de la extensión del XFC (ver Algoritmo 2).

Algoritmo 2 Habilitación del manejador CGI mediante FilesMatch, sindeshabilitar mod_php

<Directory "/<root_path>/application">


<FilesMatch "\.php$">


</FilesMatch>

AllowOverride None

</Directory>



La siguiente tabla muestra el resumen de las pruebas realizadas:

Prueba realizada Respuesta prioritariaHabilitación del manejador de scripts CGI

1.A mod_phpsimultáneamente con el módulo php5 habilitado

Deshabilitación de mod_php 1.B manejador CGI

Implementación de las instrucciones1.C mod_php

RemoveHandler .php y RemoveLanguage .php

Modi�cación de la extensión del XFC por .foo 1.D manejador CGI

Habilitación del manejador CGI mediante1.E manejador CGI

captura de la extensión de archivo .php

Cuadro 2: El manejador CGI respondió a la solicitud en 3 casos: al deshabilitarel módulo php5 (PRUEBA 1.B); al cambiar la extensión del controlador frontal(PRUEBA 1.D) y al activar el manejador CGI previa captura de la extensión.php (PRUEBA 1.E).

4.2.2. Valoración de resultados

La PRUEBA 1.B puede considerarse una alternativa viable en servidores

destinados al hospedaje de un único VirtualHost. Sin embargo, restringe la

adaptabilidad del programa a los cambios del sistema y el sistema, se ve

limitado por el requerimiento del programa. Por lo tanto, viola el principio

de independencia.

La PRUEBA 1.D se realizó a �nes orientativos pero debido a su pragmatismo

no argumentativo, carece de valor metodológico por lo que su implementación

se descarta.

La PRUEBA 1.E responde a los �nes metodológicos sin presentar efectos

negativos adyacentes que requieran de tratamiento especial.

4.3. Consideraciones particulares sobre los archivos de

con�guración general y distribuido (httpd.conf y

.htaccess)

Los archivos .htaccess se utilizan para realizar modi�caciones en la con�guración

del servidor HTTP de Apache, a nivel de directorios especí�cos.

Su uso ralentiza el servidor HTTP. Por lo tanto, se debe evitar el uso de archivos

.htaccess por completo si se tiene acceso al archivo de con�guración principal



del servidor httpd (Apache HTTP Server Tutorial: .htaccess �les, consultado el

7/12/2016 a las 15:49 UTC).

5. Política de nombres para módulos, modelos,

vistas y controladores

5.1. Política de nombres

Se utiliza como nombre de módulo el nombre del modelo. Se utilizan el

nombre del modelo con los su�jos �View� y �Controller� para crear las vistas y

controladores respectivamente.

La siguiente tabla de�ne el formato BNF para nombres de módulos y clases de

la tríada model-view-controller:

Componente Formato Ejemplos

MÓDULO <modelo>[.py|php|rb|pl|<other>] foo.py | foo

MODELO <Modelo> Foo

VISTA <Modelo>View FooView

CONTROLADOR <Modelo>Controller FooController

5.2. Formato de la URI

/<modulo|modelo>/<recurso>[/<argumento>]

Ejemplos:

/producto/agregar

Supone la existencia del archivo:

<project>/application/modules/producto.<ext>

y de las clases:

Producto, ProductoView y ProductoController.

/usuario/ver/12

/cliente/buscar/álvarez+pérez



Los valores <12> y <álvarez+pérez> suponen argumentos con los

que trabajarán los recursos UsuarioController.ver y ClienteCon-

troller.buscar respectivamente.

6. Archivo de control frontal ejecutable (eXe-

cutable Front Controller - XFC-)

6.1. Objetivo

Manejar todas las solicitudes cursadas a la aplicación a excepción de las

peticiones al directorio estático.

6.2. Responsabilidades

1. Invocar al controlador del módulo solicitado por el usuario.

2. Manejar las solicitudes erróneas o mal formuladas.

6.3. Características

Dado que:

1. los objetos se manejan como punteros íntegramente en memoria;

2. la responsabilidad del XFC es netamente funcional, careciendo de

atributos que lo hagan distintivo; y, que

3. la actuación del XFC es volátil y temporal.

se prescinde de tratar al XFC como un objeto, a �n de evitar mantener en

memoria un componente cuya función es procedimental y carente de atributos

distintivos. Por lo tanto, las �guras de un Application Handler y Application

Helper carecerían de coherencia lógica aplicable.

Se establece al XFC como único responsable del control general de la aplicación.



6.4. Llamada al controlador solicitado

6.4.1. Saneamiento de variables de entorno implicadas

(ver sección: �Archivo de inicialización de variables de entorno de la aplicación�)

6.4.2. Validación de la solicitud

Se entiende como �recurso público� a cualquier método de un controlador,

cuya instanciación sea consecuencia de una solicitud directa desde la URL.

Se instancia el controlador (C), si -y solo sí- el módulo (m) se encuentra en el

directorio de módulos (M) del sistema.

(m ∈ M) ⇐⇒ C

Con esta única validación se previene la importación de componentes que no

contengan recursos públicos.

Se invoca el recurso (r) solo si es atributo del controlador (C):

(r ∈ C) ⇐⇒ r

6.5. Manejo de solicitudes erróneas

Se considera solicitud errónea -o error request- (err(Rq)) a cualquier petición

donde:

(¬C) ∨ (¬r) ⇒ err(Rq)

Al recibirse un err(Rq), se realiza una redirección (location()) a un recurso

prede�nido por defecto (rn) o se establece (set()) el código de estado (st) del

servidor HTTP, a 404 Not Found:

err(Rq) ⇒ location(rn) ∨ set(st, 404)



6.5.1. Cuestiones de seguridad en la modi�cación del código de

estado

Cuando el código de estado es establecido a 404 Not Found y enviado como

campo de cabecera, si un campo de cabecera del tipo Content-type no es

enviado, el servidor podría exponer el intérprete del script CGI como se muestra

en el siguiente cuadro:

eugenia@debian-warrior:~/lab/mvcgi$ wget -S http://mvcgi.local/not/found--2016-12-04 20:26:38-- http://mvcgi.local/not/foundResolviendo mvcgi.local (mvcgi.local)... 127.0.0.1Conectando con mvcgi.local (mvcgi.local)[127.0.0.1]:80... conectado.Petición HTTP enviada, esperando respuesta...

HTTP/1.1 404 Not FoundDate: Sun, 04 Dec 2016 23:26:38 GMTServer: Apache/2.2.22 (Debian)Keep-Alive: timeout=5, max=100Connection: Keep-AliveTransfer-Encoding: chunkedContent-Type: text/x-python

2016-12-04 20:26:38 ERROR 404: Not Found.

Cuadro 3: Respuesta enviada por el servidor HTTP a una solicitud errónea. Elcódigo de estado se modi�ca sin modi�car el campo Content-type. El servidor,revela el intérprete del script.

Por lo tanto, el campo de encabezado Content-type (MIME), debe ser enviado

cuando un campo de cabecera Status es modi�cado y toda vez que se deba

enviar una respuesta estática (sin redirección).

err(Rq) ⇒ location(rn) ∨ (set(St, 404) ∧ set(MIME))

6.6. Modi�cación de los códigos de respuesta del servidor

HTTP

La línea de inicio de la respuesta del servidor HTTP -incluyendo la versión del

servidor (HTTP/1.1)- es respondida por el propio servidor inmediatamente al

recibir la solicitud. A nivel del programa CGI, deben emplearse los campos de

encabezado a �n de modi�car cualquier cabecera que se desee que el servidor

HTTP responda.

Por lo tanto, para modi�car el código de estado, debe emplearse �Status� como

campo de encabezado, con su código de estado correspondiente, de�niendo dicha

respuesta con el siguiente formato:



Status: <status-code> <reason-phrase>\n

Ejemplos:

Status: 404 Not Found\n

Status: 307 Temporary Redirect\n

Ver sección 9 en la página 21 para un resumen de la RFC7230 destinada a

la sintaxis de los mensajes del protocolo HTTP [RFC7230: Hypertext Transfer

Protocol (HTTP/1.1): Message Syntax and Routing ].

6.7. Código de ejemplo de un XFC en Python

Este algoritmo toma todas las CONSTANTES de entorno de la aplicación desde el

archivo de inicialización de variables (ver sección �Archivo de Inicialización de

Variables�).

# Para la comprobación de C y m

error_module = error_resource = True

# Implementación de (m ∈ M) ⇐⇒ C

if isfile(MODULE_PATH):

modulo = __import__(PACKAGE, fromlist=[CONTROLLER])

controller = getattr(modulo, CONTROLLER)()

error_module = False

# Implementación de (r ∈ C) ⇐⇒ r

if not error_module and hasattr(controller, RESOURCE):

getattr(controller, RESOURCE)()

error_resource = False

# Implementación de:

# err(Rq) ⇒ location(rn) ∨ (set(st, 404) ∧ set(MIME))

if error_module or error_resource:

error_header = "{}{}\n".format(HTTP_404, HTTP_HTML)

print error_header if SHOW_ERROR_404 else HTTP_REDIRECT



7. Archivo de inicialización de variables de

entorno de la aplicación

7.1. Responsabilidad del archivo de inicialización de

variables

Es responsabilidad de este archivo la inicialización de las variables de entorno

de la aplicación y su correspondiente saneamiento.

7.2. Variables de entorno

Se de�nen las siguientes variables, como variables de entorno de ámbito global.

Las variables de entorno no son variables con�gurables.

Variables con�gurables son de�nidas en el archivo de con�guración e

importadas por el archivo de inicialización.

URI_LIST Cada una de las partes que conforman el valor de REQUEST_URI,

utilizando como elemento divisor la barra diagonal �/�. Necesaria

para el análisis de la URI (a partir de la URI se obtiene el módulo

y el recurso solicitado por el usuario).

MODULE Nombre del módulo solicitado por el usuario (primer elemento de

la URI luego de la primera �/�). Necesaria para obtener la ruta del

archivo y los nombres de las clases de la tríada MVC.

PACKAGE Espacio de nombre del módulo en el sistema. Necesario para su

importación.

MODULE_PATH Ruta del archivo del módulo. Necesaria para validar que se trate

de un módulo autorizado.

CONTROLLER Nombre del controlador a ser instanciado.

RESOURCE Nombre del recurso (del controlador) a ser invocado.

ARG Valor del argumento pasado por la URI.



Variables exclusivas para modi�cación de las cabeceras del servidor

HTTP:

HTTP_404 Cadena de respuesta del servidor HTTP/1.1 para solicitudes

erróneas, con el campo de encabezado �Status�: Status: 404 Not

Found\n

HTTP_HTML Cadena de respuesta del servidor HTTP/1.1 para solicitudes de

contenido HTML: Content-type: text/html; charset=utf-8\n

REDIRECT_URL Cadena de respuesta del servidor HTTP/1.1 para redirecciones

en caso de solicitudes erróneas que no sean respondidas con un

código de respuesta 404.

7.3. Cuestiones de seguridad relativas a la inicialización

de las variables

MODULE

Nombres de módulo que contengan el signo �.� podrían provocar una

vulnerabilidad de seguridad en la validación de la ruta. Deberán sustituirse

todas las apariciones del �.� (punto) en el nombre del módulo ANTES de ser

asignado como valor de MODULE.

MODULE = <valor>.replace('.', �)

RESOURCE, ARG

Un valor NULL o FALSE en estas variables, podría generar respuestas inesperadas

en la aplicación provocando en consecuencia, un exceso de validaciones

destinadas a prevenir vulnerabilidades de seguridad.

El uso de condicionales ternarios para establecer un valor por defecto en caso

de valores nulos se postula como alternativa viable.

Ejemplo en Python:

RESOURCE = URI_LIST[1] if len(URI_LIST) > 1 else �



Mismo ejemplo en PHP:

$RESOURCE = (count($URI_LIST) > 1) ? $URI_LIST[1] : �;

Aproximación en Ruby:

RESOURCE = (URL_LIST.length > 1) ? URI_LIST[1] : �

Aproximación en Perl:

$RESOURCE = (@URL_LIST > 1) ? $URI_LIST[1] : �;

AVISO: el código fuente citado como �aproximación� debería ser validado antes

de su implementación.

8. Archivo de con�guración

Se destina el archivo de con�guración a la de�nición de toda aquella variable

cuyo valor relativo dependa del núcleo o motor del programa.

Corresponde al desarrollador de frameworks o Ingeniero del núcleo, de�nir las

variables que sean necesarias en este archivo.

Corresponde al programador de aplicaciones de usuario (aplicación �nal)

con�gurar el valor de las variables de�nidas en este archivo.

Las variables de�nidas en el archivo de con�guración son requeridas por el

archivo de inicialización de variables de entorno. La de�nición de variables

de con�guración por parte del programador de aplicaciones de usuario podría

generar vulnerabilidades de seguridad imprevistas. A criterio del desarrollador

de frameworks o Ingeniero del núcleo queda permitir -o no- el agregado

de variables en este archivo y en consecuencia, a su responsabilidad queda

implementar las medidas de seguridad necesarias para evitar la aparición de

vulnerabilidades que afecten al núcleo del sistema.



8.1. Variables de con�guración sugeridas

Estas variables podrían ser requeridas por el archivo de inicialización y/o por el

XFC:

string DEFAULT_RESOURCE

De�nición de la URI de un recurso por defecto. Necesaria para el

manejo de solicitudes erróneas.

bool SHOW_ERROR_404

Se establece en True para responder un código de estado 404 en caso

de solicitud errónea.

Se establece en False, para redirigir al recurso por defecto en el

mismo escenario.

9. Consideraciones generales sobre los encabeza-

dos del servidor HTTP/1.1

9.1. Aviso legal sobre la sección

Las recomendaciones de seguridad de esta sección se basan en su totalidad, en

las recomendaciones de Fielding & Reschke expuestas en la RFC7230. Dada la

condición restrictiva de la licencia de publicación de las RCF, esta sección se

ha limitado a la cita de las partes signi�cativas de la misma pero se ha evitado

cualquier interpretación, mejora o trabajo derivado de la misma.

Las RFC citadas en esta sección son de licencia privativa. Este

documento es de licencia libre. En trabajos derivados de este

documento, la licencia privativa de las RFC, podría afectar

directamente a la obra derivada. Se recomienda evitar la mención de

esta sección y referirse a las fuentes originales, para evitar con�ictos

legales en los trabajos derivados.



9.2. Recomendaciones para la modi�cación de encabeza-

dos según las RFC

La RFC7230 postula que todos los mensajes HTTP/1.1 deben comenzar con

una línea de inicio seguida de cero o más líneas de campos de cabecera, una

línea vacía que indique el �nal de la sección de cabeceras y, opcionalmente, un

cuerpo de mensaje (Fielding & Reschke, 2014).

start-line

*(header-field CRLF)

CRLF

[message-body]

Debe tomarse la precaución de no enviar espacios en blanco entre la línea de

inicio y el primer encabezado (Fielding & Reschke, 2014).

A �n de evitar vulnerabilidades de seguridad producidas por el procesamiento

erróneo de secuencias de caracteres multibyte que contengan el octeto LF

(%x0A) (Fielding & Reschke, 2014), la codi�cación de caracteres no ASCII,

se hace explícita en la respuesta HTTP. Un ejemplo de uso correcto sería el

siguiente:

Content-type: text/html; charset=utf-8\n

9.3. Línea de inicio

Una línea de inicio puede ser de dos tipos: de solicitud o de estado (Fielding

& Reschke, 2014). Para una explicación detallada sobre las líneas de solicitud,

referirse a la sección 3.1.1 de la RFC72308.

Una línea de estado debe cumplir el siguiente formato:

<HTTP-version> <status-code> <reason-phrase>\n

HTTP-version = HTTP/<n_mayor>.<n_menor>

status-code = código de 3 dígitos (ej.: 200, 403, 404, 500)

Ejemplos:



HTTP/1.1 200 Ok\n

HTTP/1.1 404 Not Found\n

Para una lista completa de códigos de estado HTTP/1.1, véase la sección 6.1

de la RFC72319.

9.4. Campos de encabezado

Los campos de encabezado deben enviarse, luego de la línea de inicio, empleando

el siguiente formato:

<field-name>:[OWS]<field-value>[OWS]\n

OWS = Optional White Space

Sírvase ver los ejemplos de la sección 6.6 en la página 16.

9.5. Fuentes de documentación originales

Para una referencia completa sobre el comportamiento de cabeceras, referirse a

las RFC723X en https://tools.ietf.org/html/rfc<n> (sustituir <n> por la RFC

correspondiente de la siguiente lista):

RFC7230: HTTP/1.1: Message Syntax and Routing

RFC7231: HTTP/1.1: Semantics and Content

RFC7232: HTTP/1.1: Conditional Requests

RFC7233: HTTP/1.1: Range Requests

RFC7234: HTTP/1.1: Caching

RFC7235: HTTP/1.1: Authentication

10. Correspondencia

Eugenia Bahit - LAECI.org

483 Green Lanes. N13 4BS London, United Kingdom

TE: +44 (161) 818-7925

EMail: [email protected]



Notes

1RFC3875: https://tools.ietf.org/html/rfc3875

2https://httpd.apache.org/docs/current/misc/perf-tuning.html

3https://httpd.apache.org/docs/current/misc/security_tips.html

4https://httpd.apache.org/docs/current/vhosts/

5https://httpd.apache.org/docs/current/rewrite/

6https://httpd.apache.org/docs/current/howto/htaccess.html

7https://httpd.apache.org/docs/current/mod/core.html#allowoverride



Parte III

GNU Free Documentation

License

Version 1.3, 3 November 2008 Copyright © 2000, 2001, 2002, 2007, 2008 Free

Software Foundation, Inc. <http://fsf.org/> Everyone is permitted to copy

and distribute verbatim copies of this license document, but changing it is not

allowed.

Preamble

The purpose of this License is to make a manual, textbook, or other functional

and useful document �free� in the sense of freedom: to assure everyone the

e�ective freedom to copy and redistribute it, with or without modifying it,

either commercially or noncommercially. Secondarily, this License preserves for



the author and publisher a way to get credit for their work, while not being

considered responsible for modi�cations made by others. This License is a kind of

�copyleft�, which means that derivative works of the document must themselves

be free in the same sense. It complements the GNU General Public License,

which is a copyleft license designed for free software. We have designed this

License in order to use it for manuals for free software, because free software

needs free documentation: a free program should come with manuals providing

the same freedoms that the software does. But this License is not limited to

software manuals; it can be used for any textual work, regardless of subject

matter or whether it is published as a printed book. We recommend this License

principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains

a notice placed by the copyright holder saying it can be distributed under the

terms of this License. Such a notice grants a world-wide, royalty-free license,

unlimited in duration, to use that work under the conditions stated herein. The

�Document�, below, refers to any such manual or work. Any member of the

public is a licensee, and is addressed as �you�. You accept the license if you copy,

modify or distribute the work in a way requiring permission under copyright

law. A �Modi�ed Version� of the Document means any work containing the

Document or a portion of it, either copied verbatim, or with modi�cations

and/or translated into another language. A �Secondary Section� is a named

appendix or a front-matter section of the Document that deals exclusively with

the relationship of the publishers or authors of the Document to the Document's

overall subject (or to related matters) and contains nothing that could fall

directly within that overall subject. (Thus, if the Document is in part a textbook

of mathematics, a Secondary Section may not explain any mathematics.) The

relationship could be a matter of historical connection with the subject or

with related matters, or of legal, commercial, philosophical, ethical or political

position regarding them. The �Invariant Sections� are certain Secondary

Sections whose titles are designated, as being those of Invariant Sections, in

the notice that says that the Document is released under this License. If a

section does not �t the above de�nition of Secondary then it is not allowed to

be designated as Invariant. The Document may contain zero Invariant Sections.

If the Document does not identify any Invariant Sections then there are none.

The �Cover Texts� are certain short passages of text that are listed, as Front-

Cover Texts or Back-Cover Texts, in the notice that says that the Document



is released under this License. A Front-Cover Text may be at most 5 words,

and a Back-Cover Text may be at most 25 words. A �Transparent� copy of

the Document means a machine-readable copy, represented in a format whose

speci�cation is available to the general public, that is suitable for revising the

document straightforwardly with generic text editors or (for images composed of

pixels) generic paint programs or (for drawings) some widely available drawing

editor, and that is suitable for input to text formatters or for automatic

translation to a variety of formats suitable for input to text formatters. A copy

made in an otherwise Transparent �le format whose markup, or absence of

markup, has been arranged to thwart or discourage subsequent modi�cation

by readers is not Transparent. An image format is not Transparent if used

for any substantial amount of text. A copy that is not �Transparent� is called

�Opaque�. Examples of suitable formats for Transparent copies include plain

ASCII without markup, Texinfo input format, LaTeX input format, SGML or

XML using a publicly available DTD, and standard-conforming simple HTML,

PostScript or PDF designed for human modi�cation. Examples of transparent

image formats include PNG, XCF and JPG. Opaque formats include proprietary

formats that can be read and edited only by proprietary word processors, SGML

or XML for which the DTD and/or processing tools are not generally available,

and the machine-generated HTML, PostScript or PDF produced by some word

processors for output purposes only. The �Title Page� means, for a printed

book, the title page itself, plus such following pages as are needed to hold,

legibly, the material this License requires to appear in the title page. For works

in formats which do not have any title page as such, �Title Page� means the text

near the most prominent appearance of the work's title, preceding the beginning

of the body of the text. The �publisher� means any person or entity that

distributes copies of the Document to the public. A section �Entitled XYZ�

means a named subunit of the Document whose title either is precisely XYZ

or contains XYZ in parentheses following text that translates XYZ in another

language. (Here XYZ stands for a speci�c section name mentioned below, such

as �Acknowledgements�, �Dedications�, �Endorsements�, or �History�.)

To �Preserve the Title� of such a section when you modify the Document

means that it remains a section �Entitled XYZ� according to this de�nition.

The Document may include Warranty Disclaimers next to the notice which

states that this License applies to the Document. These Warranty Disclaimers

are considered to be included by reference in this License, but only as regards

disclaiming warranties: any other implication that these Warranty Disclaimers

may have is void and has no e�ect on the meaning of this License.



2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially

or noncommercially, provided that this License, the copyright notices, and the

license notice saying this License applies to the Document are reproduced in

all copies, and that you add no other conditions whatsoever to those of this

License. You may not use technical measures to obstruct or control the reading

or further copying of the copies you make or distribute. However, you may accept

compensation in exchange for copies. If you distribute a large enough number

of copies you must also follow the conditions in section 3. You may also lend

copies, under the same conditions stated above, and you may publicly display

copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed

covers) of the Document, numbering more than 100, and the Document's license

notice requires Cover Texts, you must enclose the copies in covers that carry,

clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover,

and Back-Cover Texts on the back cover. Both covers must also clearly and

legibly identify you as the publisher of these copies. The front cover must present

the full title with all words of the title equally prominent and visible. You may

add other material on the covers in addition. Copying with changes limited

to the covers, as long as they preserve the title of the Document and satisfy

these conditions, can be treated as verbatim copying in other respects. If the

required texts for either cover are too voluminous to �t legibly, you should

put the �rst ones listed (as many as �t reasonably) on the actual cover, and

continue the rest onto adjacent pages. If you publish or distribute Opaque copies

of the Document numbering more than 100, you must either include a machine-

readable Transparent copy along with each Opaque copy, or state in or with

each Opaque copy a computer-network location from which the general network-

using public has access to download using public-standard network protocols a

complete Transparent copy of the Document, free of added material. If you

use the latter option, you must take reasonably prudent steps, when you begin

distribution of Opaque copies in quantity, to ensure that this Transparent copy

will remain thus accessible at the stated location until at least one year after

the last time you distribute an Opaque copy (directly or through your agents

or retailers) of that edition to the public. It is requested, but not required, that

you contact the authors of the Document well before redistributing any large



number of copies, to give them a chance to provide you with an updated version

of the Document.

4. MODIFICATIONS

You may copy and distribute a Modi�ed Version of the Document under the

conditions of sections 2 and 3 above, provided that you release the Modi�ed

Version under precisely this License, with the Modi�ed Version �lling the role

of the Document, thus licensing distribution and modi�cation of the Modi�ed

Version to whoever possesses a copy of it. In addition, you must do these things

in the Modi�ed Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that

of the Document, and from those of previous versions (which should, if

there were any, be listed in the History section of the Document). You

may use the same title as a previous version if the original publisher of

that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities

responsible for authorship of the modi�cations in the Modi�ed Version,

together with at least �ve of the principal authors of the Document (all

of its principal authors, if it has fewer than �ve), unless they release you

from this requirement.

C. State on the Title page the name of the publisher of the Modi�ed Version,

as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modi�cations adjacent to

the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giving

the public permission to use the Modi�ed Version under the terms of this

License, in the form shown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections and

required Cover Texts given in the Document's license notice.

H. Include an unaltered copy of this License.



I. Preserve the section Entitled �History�, Preserve its Title, and add to it

an item stating at least the title, year, new authors, and publisher of the

Modi�ed Version as given on the Title Page. If there is no section Entitled

�History� in the Document, create one stating the title, year, authors, and

publisher of the Document as given on its Title Page, then add an item

describing the Modi�ed Version as stated in the previous sentence.

J. Preserve the network location, if any, given in the Document for public

access to a Transparent copy of the Document, and likewise the network

locations given in the Document for previous versions it was based on.

These may be placed in the �History� section. You may omit a network

location for a work that was published at least four years before the

Document itself, or if the original publisher of the version it refers to

gives permission.

K. For any section Entitled �Acknowledgements� or �Dedications�, Preserve

the Title of the section, and preserve in the section all the substance and

tone of each of the contributor acknowledgements and/or dedications given

therein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text

and in their titles. Section numbers or the equivalent are not considered

part of the section titles.

M. Delete any section Entitled �Endorsements�. Such a section may not be

included in the Modi�ed Version.

N. Do not retitle any existing section to be Entitled �Endorsements� or to

con�ict in title with any Invariant Section.

O. Preserve any Warranty Disclaimers.

If the Modi�ed Version includes new front-matter sections or appendices

that qualify as Secondary Sections and contain no material copied from the

Document, you may at your option designate some or all of these sections

as invariant. To do this, add their titles to the list of Invariant Sections in

the Modi�ed Version's license notice. These titles must be distinct from any

other section titles. You may add a section Entitled �Endorsements�, provided it

contains nothing but endorsements of your Modi�ed Version by various parties�

for example, statements of peer review or that the text has been approved by

an organization as the authoritative de�nition of a standard. You may add a

passage of up to �ve words as a Front-Cover Text, and a passage of up to 25

words as a Back-Cover Text, to the end of the list of Cover Texts in the Modi�ed



Version. Only one passage of Front-Cover Text and one of Back-Cover Text may

be added by (or through arrangements made by) any one entity. If the Document

already includes a cover text for the same cover, previously added by you or by

arrangement made by the same entity you are acting on behalf of, you may not

add another; but you may replace the old one, on explicit permission from the

previous publisher that added the old one. The author(s) and publisher(s) of

the Document do not by this License give permission to use their names for

publicity for or to assert or imply endorsement of any Modi�ed Version.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this

License, under the terms de�ned in section 4 above for modi�ed versions,

provided that you include in the combination all of the Invariant Sections of all

of the original documents, unmodi�ed, and list them all as Invariant Sections

of your combined work in its license notice, and that you preserve all their

Warranty Disclaimers. The combined work need only contain one copy of this

License, and multiple identical Invariant Sections may be replaced with a single

copy. If there are multiple Invariant Sections with the same name but di�erent

contents, make the title of each such section unique by adding at the end of it,

in parentheses, the name of the original author or publisher of that section if

known, or else a unique number. Make the same adjustment to the section titles

in the list of Invariant Sections in the license notice of the combined work. In the

combination, you must combine any sections Entitled �History� in the various

original documents, forming one section Entitled �History�; likewise combine any

sections Entitled �Acknowledgements�, and any sections Entitled �Dedications�.

You must delete all sections Entitled �Endorsements�.

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents

released under this License, and replace the individual copies of this License

in the various documents with a single copy that is included in the collection,

provided that you follow the rules of this License for verbatim copying of each

of the documents in all other respects. You may extract a single document from

such a collection, and distribute it individually under this License, provided you

insert a copy of this License into the extracted document, and follow this License

in all other respects regarding verbatim copying of that document.



7. AGGREGATION WITH INDEPENDENT

WORKS

A compilation of the Document or its derivatives with other separate and

independent documents or works, in or on a volume of a storage or distribution

medium, is called an �aggregate� if the copyright resulting from the compilation

is not used to limit the legal rights of the compilation's users beyond what

the individual works permit. When the Document is included in an aggregate,

this License does not apply to the other works in the aggregate which are not

themselves derivative works of the Document. If the Cover Text requirement of

section 3 is applicable to these copies of the Document, then if the Document

is less than one half of the entire aggregate, the Document's Cover Texts may

be placed on covers that bracket the Document within the aggregate, or the

electronic equivalent of covers if the Document is in electronic form. Otherwise

they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modi�cation, so you may distribute

translations of the Document under the terms of section 4. Replacing Invariant

Sections with translations requires special permission from their copyright

holders, but you may include translations of some or all Invariant Sections in

addition to the original versions of these Invariant Sections. You may include

a translation of this License, and all the license notices in the Document, and

any Warranty Disclaimers, provided that you also include the original English

version of this License and the original versions of those notices and disclaimers.

In case of a disagreement between the translation and the original version of this

License or a notice or disclaimer, the original version will prevail. If a section in

the Document is Entitled �Acknowledgements�, �Dedications�, or �History�, the

requirement (section 4) to Preserve its Title (section 1) will typically require

changing the actual title.

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as

expressly provided under this License. Any attempt otherwise to copy, modify,

sublicense, or distribute it is void, and will automatically terminate your rights



under this License. However, if you cease all violation of this License, then your

license from a particular copyright holder is reinstated (a) provisionally, unless

and until the copyright holder explicitly and �nally terminates your license, and

(b) permanently, if the copyright holder fails to notify you of the violation by

some reasonable means prior to 60 days after the cessation. Moreover, your

license from a particular copyright holder is reinstated permanently if the

copyright holder noti�es you of the violation by some reasonable means, this

is the �rst time you have received notice of violation of this License (for any

work) from that copyright holder, and you cure the violation prior to 30 days

after your receipt of the notice. Termination of your rights under this section

does not terminate the licenses of parties who have received copies or rights from

you under this License. If your rights have been terminated and not permanently

reinstated, receipt of a copy of some or all of the same material does not give

you any rights to use it.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU

Free Documentation License from time to time. Such new versions will be

similar in spirit to the present version, but may di�er in detail to address new

problems or concerns. See http://www.gnu.org/copyleft/. Each version of

the License is given a distinguishing version number. If the Document speci�es

that a particular numbered version of this License �or any later version� applies

to it, you have the option of following the terms and conditions either of that

speci�ed version or of any later version that has been published (not as a draft)

by the Free Software Foundation. If the Document does not specify a version

number of this License, you may choose any version ever published (not as a

draft) by the Free Software Foundation. If the Document speci�es that a proxy

can decide which future versions of this License can be used, that proxy's public

statement of acceptance of a version permanently authorizes you to choose that

version for the Document.

11. RELICENSING

�Massive Multiauthor Collaboration Site� (or �MMC Site�) means any World

Wide Web server that publishes copyrightable works and also provides

prominent facilities for anybody to edit those works. A public wiki that

anybody can edit is an example of such a server. A �Massive Multiauthor



Collaboration� (or �MMC�) contained in the site means any set of copyrightable

works thus published on the MMC site. �CC-BY-SA� means the Creative

Commons Attribution-Share Alike 3.0 license published by Creative Commons

Corporation, a not-for-pro�t corporation with a principal place of business in

San Francisco, California, as well as future copyleft versions of that license

published by that same organization. �Incorporate� means to publish or

republish a Document, in whole or in part, as part of another Document. An

MMC is �eligible for relicensing� if it is licensed under this License, and if all

works that were �rst published under this License somewhere other than this

MMC, and subsequently incorporated in whole or in part into the MMC, (1)

had no cover texts or invariant sections, and (2) were thus incorporated prior

to November 1, 2008. The operator of an MMC Site may republish an MMC

contained in the site under CC-BY-SA on the same site at any time before

August 1, 2009, provided the MMC is eligible for relicensing.


MVCGI: Modelo de Implementación Estándar para ... · MVCGI: Modelo de Implementación Estándar...

Documents

Transcript of MVCGI: Modelo de Implementación Estándar para ... · MVCGI: Modelo de Implementación Estándar...