26 Dec, 2011, worldofrevenge wrote in the 1st comment:
Votes: 0
Using 1stMUD3.9 version and currently would like to get the webserver to work correctly. It uses +5 of my mud port. Example I use port 4500 and the port the webserver uses is 4505. When I go to my site.. http://worldofrevenge.org:4505 it gives me the html script and not the full page that it should display. I don't understand why it's doing this and not displaying the html correctly. Any suggestions would be greatly appreciated..

Please email me at webmaster@worldofrevenge.org with any suggestions!
26 Dec, 2011, Runter wrote in the 2nd comment:
Votes: 0
What are you expecting the page to be? Why is this wrong?
26 Dec, 2011, Idealiad wrote in the 3rd comment:
Votes: 0
Just checked it now and it works for me.
26 Dec, 2011, worldofrevenge wrote in the 4th comment:
Votes: 0
Well when I put it into adobe it shows it as an actual page with buttons and a background etc. I just don't understand why it's showing me the html and not actually displaying what it says.
26 Dec, 2011, worldofrevenge wrote in the 5th comment:
Votes: 0
I guess it's just a Firefox issue, because I tried on another browser and it works… dunno how to fix that I guess.
26 Dec, 2011, Dean wrote in the 6th comment:
Votes: 0
This may or may not be a start: validate
26 Dec, 2011, worldofrevenge wrote in the 7th comment:
Votes: 0
I appreciate your help! Thank you very much. Still trying to figure out why it works for some browsers and not others. lol.
26 Dec, 2011, plamzi wrote in the 8th comment:
Votes: 0
look at the raw output from the webserver; is something escaping the <> chars? (& lt; & gt;) is the content type header set properly for all browsers? (use a web debugger like fiddler2)
26 Dec, 2011, Cratylus wrote in the 9th comment:
Votes: 0
I ran into something like this. Firefox at some point started being finicky
about content type and your typical home-brew web server in a mud wasn't
put together by someone really into standards compliance.

The way I fixed it was by adding the content header as prefix to any page
sent, like so:

HTTP/1.0 200 OK\nContent-Type: text/html\r\n\r\n

Note the double CRLF at the end there, that's important to delimit the end of your HTTP header.

Kind of annoying that other browsers are happy to assume content based on file extension
but Firefox has to be analer than thou.

In fairness, probably your web server should hew to some basic standards :)

27 Dec, 2011, worldofrevenge wrote in the 10th comment:
Votes: 0
Thank you! That fixed the problem.
27 Dec, 2011, Runter wrote in the 11th comment:
Votes: 0
I would prefer if no browsers attempted to render a document that doesn't include content-type. The issue rarely comes up, since most reasonable people use web servers that do the header formation for you. The browser hits a route and gets bytes of data back. Which may or may not be derived from a file. However, the browser isn't privy to this, or to the file for that matter. The route may contain an extension in some cases. "www.somesite.com/index.html" I don't believe other than content-type there is any way other than just guessing/assuming html to divine the file extension if not given. In this case it was not given.

Anyways, you'll end up finding a lot of situations where in some browsers if you're missing things that are said to be essential it just won't work. For example, forgetting the title tag in the document header can cause serious problems in some browsers and work fine in others.

It's good practice to run the page through a validator even if it's working for you. Because, as you've seen, invalid pages can cause issues in other browsers. The old "liberal in what you accept, conservative in what you send" thing may ring true, but remember…most importantly is upholding what you have control over. Being conservative in what you send. We can't really complain that more browsers didn't accept our invalid data. :p
27 Dec, 2011, Runter wrote in the 12th comment:
Votes: 0
To clarity, I mean web servers as in both software that serves content (maybe like apache) and libraries that help your software serve content, like Express from node.js. http://expressjs.com/

And it's not really unreasonable to want to implement a webserver yourself, but you must be careful to implement it correctly and fully, or you will not be futureproof.