• Il server richiede l'autenticazione dell'utente che effettua le richieste.
• l'autenticazione è basata su una coppia utente/password; 
• l'inserimento della coppia utente/password avviene utilizzando un URL con la seguente forma:
• Il server deve offrire le stesse funzionalità sotto Linux e Windows.
• la scelta della modalità (multi-thread o multi-processo) deve poter essere effettuata all'atto della
  partenze (tramite opzioni e/o lettura di un file di configurazione).
• le scelte sul numero di thread o processi e sulla porta su cui rimane in attesa il server devono essere
  modificabili tramite opzioni e/o lettura di un file di configurazione.
• Il server rilegge il file di configurazione in caso di invio di un segnale (sighup) per la versione Linux o
  di un evento di console per la versione Windows.
  
• Ogni richiesta deve essere gestita con una nuova connessione
  (non è richiesto implementare il concetto di sessione)
• Il server mantiene un log delle operazioni effettuate nello stile del common log format che aggiunge per ogni richiesta una
  linea del tipo:
  80.116.239.218 - - [17/Jul/2002:18:29:19 +0200]  "GET /attivita/convegno1/libro1/gz/06-trio.ps.gz HTTP/1.0" 200 65536
  il significato dei diversi campi verrà spiegato a lezione (ed è comunque facilmente reperibile in Internet).
• L'esecuzione dei comandi deve essere richiesta utilizzando un URL che contiene come primo elemento del path la stringa
  command. Ad esempio:
  http://joeb:xx123@www.mysite.org:8080/command/date
  richiede l'esecuzione del comando date ed aspetta in risposta il relativo output.
• E' richiesto il supporto solo per HTTP 1.0 (RFC1945)
• una semplice guida ad http è disponibile su http://jmarshall.com/easy/http/
• per l'upload di file è richiesto il supporto per il metodo PUT.
• per l'upload dei file si può usare come client, ad esempio, il comando curl con l'opzione -T /--upload-file.
  
• i file devono essere acceduti (sia in upload che in download) in modalità esclusiva. 
• è richiesto quindi un meccanismo di lock per l'accesso ai file.
• i file di dimensione inferiore ad una soglia prefissata (ad esempio 1 MB) devono essere mappati in memoria prima
  di essere inviati e mantenuti in memoria per un certo intervallo di tempo (ad esempio 15 minuti, intervallo modificabile tramite il file di configurazione) per essere inviati direttamente in caso di nuove richieste senza dover essere di nuovo letti da disco.
  
  • Non è richiesto un meccanismo di controllo che il file sia stato modificato nel periodo in cui è mantenuto in memoria. 
  • Il numero massimo di file da mantenere in memoria è fissato (ad esempio 32 file) ma modificabile tramite il file di configurazione. Se viene superato tale limite, viene eliminato il file che è da più tempo in memoria.
• I codici di ritorno devono essere in accordo con le convenzioni HTTP
• codici numeri di tre cifre, con la prima cifra che indica se la richiesta è andata a buon fine
• Il server deve funzionare in maniera indipendente dal protocollo di livello network (IPv4 o IPv6).
• Il server deve essere interrogabile tramite i comuni  browser. Non è richiesto lo sviluppo di un client.
  

Opzionale: permettere di ritornare chiavi del register Windows oltre ai file.
In questo caso l'URL deve contenere come primo elemento del path la stringa register e di seguito la chiave richiesta. Ad esempio:
http://joeb:xx123@www.mysite.org:8080/register/HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

Al progetto andrà allegata una breve (5-10 pagine) relazione che descriva (e motivi) le scelte progettuali.