"Shane P. Lee" wrote:
>
> Hrmm, I hope I'm not being too redundant here. Anyways, here's
> the addy for the sourcode:
Sorry about taking so long with this, I had to find some time when I
could really sit down and hunt through the source. After looking through
the source I can tell you that the client is indeed using HTTP 1.0 which
does not support name-based virtual hosting. Converting the entire
client to http 1.1 so that it's fully compliant with the newer standard
would be way more trouble than it's worth, as you would have to modify
the way the client interacts with the server. One of the biggest hurdles
would be to make it so that the client can step back down to HTTP 1.0 in
case the server does not support 1.1. If you want to make the client
fully 1.1 compliant than you are more than welcome to do so. You can
find all the information you'll need about the specification in RFC 2068
(http://www.w3.org/Protocols/rfc2068/rfc2068).
The good news is that the client does not have to be _fully_ HTTP 1.1
compliant in order to interact with an HTTP 1.1 server and work with
virtual name-based hosts. All that is required is that the request
headers be modified in such a way as to make the server _think_ that the
client is HTTP 1.1 compliant. There are also a couple minor differences
in the way that the server will act when it's talking HTTP 1.1 rather
than HTTP 1.0.
1. The server will wait for a blank line after it recieves the request
before it attempts to act on the request. This allows the client to pass
additional option headers after it sends the initial request.
2. The server will, by default, not close the connection to the client
after the file is recieved. This is different from the default behavior
of HTTP 1.0 which always closes the connection immediately after sending
a file. Since this client is really a 1.0 client it will expect the
connection to be closed by the server, so we must pass an additional
header line to the server as a part of our request which will override
its default and make it close the connection immediately when the file is
recieved.
As a quick example, here is the same GET request that would be sent by an
HTTP 1.0 and HTTP 1.1 client...
HTTP 1.0 client:
GET /path/to/filename HTTP/1.0\r\n
Http 1.1 client:
GET /path/to/filename HTTP/1.1\r\n
Host: www.my.webserver.com\r\n
\r\n
Both requests will return the same file, but in the second case the
server can serve up a different file depending on what hostname is passed
in the Host header on the second line. This is how virtual name-based
hosting works. Here is the same request made by our client which is
really an HTTP 1.0 client pretending to be an HTTP 1.1 client:
GET /path/to/filename HTTP/1.1\r\n
Host: www.my.webserver.com\r\n
Connection: close\r\n
\r\n
There is another problem with tweaking the headers this way. HTTP 1.1
provides a mechanism to negotiate an HTTP 1.0 or HTTP 0.9 connection with
an older server. Unfortuanately it would be beyond what I'm willing to
do to figure out hwo to implement that in the pueblo client. My solution
here is just to blindly send the HTTP 1.1 request and hope for the best.
Older web servers taht don't support HTTP 1.1 should be few and far
between, so it's unlikely that this will be a problem.
Okay, now for the solution...
edit the file pueblo/api/ChHTPriv.h and change the #define for
HTTP_VERSION to the following...
#define HTTP_VERSION "HTTP/1.1"
Now edit the file pueblo/api/ChHTPriv.cpp and find the function
ChHTTPInfo::BuildRequestLine(). At the end of the function you'll see
these two lines...
m_strRequestBuffer += strPath;
m_strRequestBuffer += strVersion;
Following those add these...
m_strRequestBuffer += "Host: ";
m_strRequestBuffer += m_urlParts.GetHostName();
m_strRequestBuffer += ":";
m_strRequestBuffer += m_urlParts.GetPortNumber();
m_strRequestBuffer += "\r\nConnection: close\r\n\r\n";
Disclaimer:
This is completely untested. Considering I know little about C++ and
even less about pueblo the probability that it won't work is extremely
high. It appears that GetHostName() and GetPortNumber() were originally
intended for proxy usage, so I'm not positive that they'll contain the
right info. If they don't have the right info then you'll have to get it
from somewhere else. GetPortNumber returns an int, but if my guess is
right the += operator will be properly overloaded to handle it. if it
isn't you'll have to convert it to a string.
<obCircle>
As long as we're on the topic of HTTP, may as well relate this to it as
well. Anyone ever do anything to integrate CircleMUD to the web in any
way that goes beyond just dumping an html file every once in a while to
be served up by a browser? While HTTP may seem ill-suited to do
MUD-related things on, it's widespread use and easily available clients
(ie web browsers) make it something that's at least minorly interesting
to think about. Anyone care to comment about the following possibilities
(and any others you can think about)...
Simple web-page dumping based on game statistics (such as a who list). I
know this has been done but I'd be remiss to leave it out.
CGI Script interaction. Possibly even making the MUD server act as a CGI
script in and of itself.
Making the MUD it's own mini-web server.
What kinds of possibilities do you see in this? The following is what I
can percieve as the various different possibilities, feel free to comment
on any of them or add to the list...
Simple statistics reporting (again, I know it's been covered).
A simple administration interface, allowing the implementor to do things
like reboot the MUD, DC characters, etc.
A coding interface. With text boxes and forms this could be accomplished
fairly easily. This might be made easier if done through something such
as CVS.
An OLC interface. A nice forms-based HTML OLC interface could end up
being something that works out well for builders.
A playing interface. This could be accomplished by a java applet, or it
could be accomplished (rather crudely) with a form interface and an
automatic timed-refresh (I've heard of chat-rooms that were done this way
before).
Comments, suggestions, stories about ex-boy/girlfriends?
Regards, Peter
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST