Własny serwer HTTP (.NET)

Witam,
w ciągu ostatnich dni napisałem własny serwer HTTP i prosiłbym o jego ocenę i propozycje dodania nowych funkcjonalności.
Projekt składa się z dwóch aplikacji: httpd - aplikacji serwera, oraz KKServerGUI - nakładka graficzna na serwer umożliwiająca modyfikowanie jego ustawień oraz jego uruchamiania i wyłączania. Wymagana biblioteka .NET w wersji min. 4.
Możliwości:

• Logowanie żądań serwera, a następnie utworzenie na podstawie logów wykresów.
• Obsługa interpretera PHP. Można dodać dowolny inny obsługujący interfejs CGI.
• Obsługa własnych stron błędów
• Transfer-encoding - normalny oraz ranges dla plików statycznych, chunk dla plików *.php i innych interpretowanych przez zewnętrzne interpretery.
• i co najważniejsze: działa :)

Jaki był cel napisania? Napisanie pierwszej aplikacji w c# oraz wykorzystującej WPF.
A teraz to, co najważniejsze - link: https://github.com/kkonczak/kkserver
Czekam na propozycje zmian. Pozdrawiam.

PS: Zamknięcie KKServerGUI nie powoduje zamknięcia aplikacji httpd. Trzeba ją zamknąć ręcznie z poziomu KKServerGUI.

Wykorzystać GitHuba tylko po to, żeby wrzucić zipa do repozytorium? Wersja skompilowana? Meh.

1. Dodaj obsługę innych metod HTTP poza GET i POST (BTW, zwracasz błąd 405, IMO powinieneś zwracać 501);
2. A może by tak pamiętać, że nie samym IPv4 człowiek żyje?
3. Może dodaj wykorzystanie jako reverse-proxy, aby móc podłączyć nie tylko CGI, ale w zasadzie cokolwiek?
4. Możesz uporządkować nieco swój kod źródłowy, bo masz trochę rzeczy, które warto by było wydzielić do oddzielnych metod - np. tworzenie nagłówków odpowiedzi HTTP robisz bardzo ręcznie w responseNormal czy errorWrite;
5. Nazewnictwo metod jest niezgodne z C#-owym podejściem, podobnie enumy, structy, delegaty;
6. Możesz pomyśleć nad zrobieniem sobie jakiegoś obiektowego opakowania do twojego pliku konfiguracyjnego, aby aplikacja graficzna i serwer nie musiały go każde samemu analizować.

W aplikacji graficznej:

1. Logs, nie Loggs :), "Enable browse directories" jest niegramatyczne;

Fajne, podoba mi się. Jak zaczniesz pisać w WPF to po pewnym czasie zainteresuj się MVVM - ja przez długi czas omijałem temat, a potem się okazało, że to ma nawet trochę sensu i jest bardzo fajne.

Już... dobrze... spokojnie... z bólem serca wrzuciłem na GitHuba cały kod całego rozwiązania, nie tylko wersję skompilowaną i każdy zainteresowany może się niemu przyjrzeć, czy nie ma w nim jakiegoś backdoora ;)
oto link: https://github.com/kkonczak/kkserver2 (i wszelkie zmiany będę wykonywał w tym repozytorium.)
Zmiany:
*Dodany nowy widok w logach (liczba zapytań na daną porę dnia)
*Dodana obsługa pluginów
*Troszeczkę refaktoryzacji kodu...
*Dodane nowe metody (OPTIONS, HEAD)

@Ktos:

1. Dodałem już obsługę OPTIONS i HEAD - już jest więcej. Co do zwracania błędów - tak, Apache zwraca 501, ale IIS już 405 - testowałem przed chwilą. Ale już zmieniłem na 501.
2. Zostawiłem ten punkt na później.
3. Patrz plugin: pluginReverseProxy.dll - czyżby o to chodziło ? ;)
4. Będę musiał to zrobić (a w sumie przy tworzeniu nagłówków już zrobiłem po części).
5. Chodzi o wielkość liter? Czy coś konkretniejszego? Jeśli o wielkość liter, to będę to stopniowo poprawiał.
6. To też w niedalekiej przyszłości, bo faktycznie, byłoby o wiele przyjemniej pracować nad tym. Ale teraz zająłem się pluginami i czasu zabrakło.

Co do aplikacji graficznej - dziękuję za zwrócenie uwagi, już poprawiłem.
MVVM - na pewno się tym zainteresuję, ale po WPF, ponieważ w wielu ofertach o prace się pojawia (a jak zacząłem WPF, to chciałbym to przerobić póki mam na to chęci).

Nie zdążyłem napisać dokumentacji do wtyczek. Ale kod jest chyba (przynajmniej trochę) przejrzysty (nie licząc pluginReverseProxy.dll).
Przykładowa konfiguracja pluginu reverseProxy:

      <setting key="requestRegEx" value="\/myTest\/(?&lt;path&gt;.*)" />
      <setting key="redirectHostName" value="google.com" />
      <setting key="redirectPath" value="/" />
      <setting key="hostHeaderRewrite" value="true" />
      <setting key="xForwardedForHeader" value="false" />

akurat google.com nie zadziała prawidłowo - bo będzie przekierowywał przeglądarkę na połączenie https (czyli już bez udziału naszego serwera). Musi to być domena na zwykłym http.

Czekam na opinie i uwagi na temat nowych funkcjonalności, poprawek itd.
Pozdrawiam :)