[Mono-list] ASP

Patrik Torstensson totte@labs2.com
Sun, 10 Feb 2002 13:21:52 +0100


The HttpWorkerRequest class is both a virtual class with some mandatory methods that you need to implement and it also contains help functions to implement the basic functions of a web server provider interface. I think we can make a implementation of the HttpWorkerRequest (just in case someone uses it) and also of the HttpRuntime, they are really only used by Microsoft but the architecture is nice. The HttpRuntime handles calling the modules and handler, there is a HttpHandleFactory to create handlers but thats simple to implement.
 
I think we can make the framework work on any webserver with only making a new managed stup for each server.
 
- Patrik

	-----Original Message----- 
	From: Piers Haken [mailto:piersh@friskit.com] 
	Sent: Sun 2002-02-10 12:46 
	To: 
	Cc: mono-list@ximian.com 
	Subject: RE: [Mono-list] ASP
	
	

	Great!
	
	I'd love to hear your thoughts on the HttpWorkerRequest class. I was
	just looking at this stuff tonight.
	
	Piers.
	
	-----Original Message-----
	From: Patrik Torstensson [mailto:totte@labs2.com]
	Sent: Sunday, February 10, 2002 3:02 AM
	To: Miguel de Icaza; Matt Liotta
	Cc: mono-list@ximian.com
	Subject: RE: [Mono-list] ASP
	
	
	Hi All,
	
	I'll describe what I almost have ready to release under the X11
	agreement.
	
	The following ASP.Net runtime classes:
	
	HttpContext    (misses link to application but that's a small issue)
	HttpResponse  (just misses a few methods)
	HttpRequest    (misses 12 methods like MapPath etc but they are easy to
	implement)
	HttpRequestStream
	HttpResponseHeaders (used to send headers)
	HttpWriter (output handling)
	
	The classes supports HTTP/1.0 and HTTP/1.1, that includes POST data
	parsing (still missing multipart parsing but that's underway) and the
	output classes supports buffering and chunked encoding.
	
	My implementation uses a provider interface [1] instead of the virtual
	HttpWorkerRequest class that ASP.Net uses. The ASP.Net runtime has a
	number of limitations and and we could make a better implementation of
	the HttpRuntime and the HttpWorkerRequest. The good thing is that the
	HttpXXX classes will easily be used on a different server like apache or
	likewise. My idea is that our HttpWorkerRequest class will implement
	thje IHttpIOHandler interface (our interface) that our web server stubs
	supports. We don't need the IISAPIRuntime interfaces.. they are MS
	internal implementation and the documentation now says : "This type
	supports the .NET Framework infrastructure and is not intended to be
	used directly from your code."
	
	I have also implemented a Server. The HttpServer and
	HttpReqsponseHandler that is the base of the HTTP/1.0 1.1 web server. It
	uses separate threads for each request (as the ASP.Net runtime) and the
	reason for that is the possibility to call end in HttpResponse. (end
	throws a thread abort exception that is the only exception you can catch
	and it will be rethrown).
	
	The HttpServer API is very simple:
	
	HttpServer()
	HttpServer(int Port)
	HttpServer(int Port, bool UseDNS)
	Listen()   // Starts the operations
	Shutdown
	SoftwareName
	ServerName
	LookupRemoteInDNS
	
	RegisterHandler(string sURLWildcard, IHttpHandler Handler);
	UnregisterHandler(IHttpHandler Handler);
	
	// TODO: Implement module support
	AddModule(IHttpModule Mod);
	RemoveModule(IHttpModule Mod);
	
	And that's it. The API names will be changed to better names. ;)
	
	The module support is not yet done because we need to HttpApplication
	first but that's again a small issue.
	
	So, this code is 95% ready and I will finialize it during the coming 2
	days so if you wait I can post it and we will have a good base. I need
	to make a number of tests also but that could be done after release to
	the community..
	
	- Patrik Torstensson
	
	[1] IHttpIOHandler
	
	string GetHttpVerbName();
	
	string GetHttpVersion();
	
	string GetProtocol(); // Should return HTTP
	
	string GetServerName(); // Should return local server name
	
	int GetLocalPort(); // Should return listen port
	
	string GetLocalAddress();
	
	string GetQuerystring();
	
	string GetRawUrl();
	
	string GetServerSoftware();
	
	string GetRemoteName();
	
	string GetRemoteAddress();
	
	string GetRequestHeaderString();
	
	string GetUnknownServerVariables(); // Same encoding as headers
	
	string GetPath(); // Should return URL path
	
	string GetPathInfo(); // Path information (extra after the .ext in the
	uri
	
	bool IsClientConnected();
	
	bool IsEntireBodyPreloaded();
	
	long GetBytesRead();
	
	byte [] GetPreloadedEntityBody();
	
	int ReadBody(byte [] buffer, int size);
	
	void SetKeepAlive(bool bKeepalive);
	
	void SendStatus(int Code, string Description);
	
	void SendResponseHeader(string header, string value);
	
	void SendResponseFromMemory(byte [] data, long Length);
	
	void FlushResponse();
	
	void CloseConnection();
	
	
	
	
	        -----Original Message-----
	        From: Miguel de Icaza [mailto:miguel@ximian.com]
	        Sent: Sun 2002-02-10 05:44
	        To: Matt Liotta
	        Cc: mono-list@ximian.com
	        Subject: RE: [Mono-list] ASP
	       
	       
	
	        > Just joined the list hours ago to see where I could contribute
	and this
	        > caught my eye. If you would like I would be happy to write a
	simple web
	        > server for the project. I would imagine that a web server
	interface would be
	        > ideal, so that others could offer their own implementation as
	time went on.
	        > The interface would need to not only abstract a web server
	built with .NET,
	        > but also allow for out of framework servers via stubs for
	NSAPI, ISAPI, and
	        > Apache mod.
	       
	        It is a good idea, I would like to start small, because if we
	start
	        small, we can always evaluate the design or adapt other
	technologies as
	        we go rather than have an all-encompassing, all-doing class and
	set of
	        interfaces.
	       
	        My request is to first get an API defined for how the Web Server
	class
	        would be defined/launched from the .NET universe, post that to
	the list,
	        and do a few iterations over it before we implement.
	       
	        Miguel
	       
	        _______________________________________________
	        Mono-list maillist  -  Mono-list@ximian.com
	        http://lists.ximian.com/mailman/listinfo/mono-list
	       
	
	
	_______________________________________________
	Mono-list maillist  -  Mono-list@ximian.com
	http://lists.ximian.com/mailman/listinfo/mono-list
	
	_______________________________________________
	Mono-list maillist  -  Mono-list@ximian.com
	http://lists.ximian.com/mailman/listinfo/mono-list