Click here to Skip to main content
Click here to Skip to main content

STL WebServer

By , 8 May 2000
 
  • Download source files - 76 Kb
  • Introduction

    This article presents code for a web server implemented using sockets and STL. The code for the web server was adapted from the httpsvr sample in MSDN. The visual interface has been removed. All of the the MFC code has been ripped out and converted to STL, and socket classes were implemented.

    The socket classes are:

    • Socket
    • ServerSocket

    These feed handler classes:

    • SocketHandler
    • ServerSocketHandler
    • HttpSocketHander

    Socket notification comes from the abstract class SocketNotify which SocketHandler implements. A reference can be passed in to override the notification.

    The http request classes are:

    • HttpBuffer
    • HttpRequest
    • HttpRquestProcess
    • HttpResponse

    The request class allows you to create requests or to store a request. The request process processes requests by passing in a pointer to a buffer. The request process class gets initial info like the URL and then forms a response.

    The startup code is in Server.cpp which declares an instance of HttpServer. To set up the code to run set the directory where your web pages are and then compile and run.

    I would like to here any comments on how to improve performance or how to better implement the web server. So if you get time email me at dghubbard@megsinet.com.

    License

    This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

    A list of licenses authors might use can be found here

    About the Author

    David Hubbard
    United States United States
    Member
    No Biography provided

    Sign Up to vote   Poor Excellent
    Add a reason or comment to your vote: x
    Votes of 3 or less require a comment

    Comments and Discussions

     
    You must Sign In to use this message board.
    Search this forum  
        Spacing  Noise  Layout  Per page   
    GeneralBUG REPORT: when input http://127.0.0.1/something.rar , IE dose NOT download the file but just show the rar file's content in IE itselfmemberadroitadroit203 Dec '06 - 16:17 
    when input http://127.0.0.1/something.rar , IE dose NOT download the file but just show the rar file's content in IE itself
     
    how to resolve this problem?
    GeneralRe: BUG REPORT: when input http://127.0.0.1/something.rar , IE dose NOT download the file but just show the rar file's content in IE itselfmembernickhalfasleep31 May '07 - 3:22 
    You need to set the content type on the header so IE knows what to expect, it just defaults to TEXT/HTML
    GeneralStream to output portmemberRobert Bielik11 Apr '06 - 21:12 
    As it is now, the entire response is built before it is sent. This is a serious overhead for large files. Instead, the content should be output to the client as soon as data is read from file.
    GeneralWhen user often click it is very busymembergiga24 Apr '05 - 17:11 
    When I often link same URL, server is very busy and CPU increase to 100% time.
    How to decrease it?Cry | :((
    Generalsome bug fixesmemberMark Timperley22 Jan '02 - 6:11 
    First I would like to thank Dave for creating and posting this code. It is obviously a work in progress, although it appears as if it has been abandoned by the author after being posted in May of 2000. Anyway, I was looking for a chunk of code that I could use as a prototype embedded web server for a quick demo. This code fit nicely with some modifications. Along the way I discovered some bugs in the original code so here they are with corrections. Hopefully this will be of use to somebody.
     
    Note that the source file is identified for each bug but the line number will be just approximate. You should be able to find the offending code by comparing the original statements, contained in the comment, and replacing them with the statements (if any) following the comment (some bug fixes just remove bad code).
     
    1) \Socket\TextFile.cpp(93):
    /* BUG MET 21Jan02
    Socket\Socket\TextFile.cpp(104): Lock::release();
    Don't release the lock before calling close() since close() must use
    (acquire) the lock to do its work. The lock should be maintained
    for the lifetime of this object. The effect of this bug is such
    that once the server opens an html file, it never releases it.
    This is annoying in the least, and at the worst, if the web site
    has many files, the server may eventually run out of file handles.
    // release lock
    Lock::release();
    */
     

    2) \Socket\HttpRequest.h(248):
    /* BUG MET 21Jan02
    The following bug prevented adding the header data to the request.
    Therefor, functions like getHeaderValue() would always fail, since
    there wasn't any header data. This was particularly annoying because
    since bodySent() uses the idParamContentLength header value to determine
    if there is any body in the message. Therefor, every message sent to this
    server appeared as if it had no body (yikes! just a head).
    if ( param.empty() == 0 || value.empty() )
    */
    if ( param.empty() || value.empty() )
     

    3) \Socket\HttpResponse.cpp(104):
    /* BUG MET 22Jan02
    AT THIS POINT size()==0, WHY ARE WE TESTING FOR size() ANYWAY?
    else if ( size() > 0 && getProcessState() == REQ_DONE &&
    */
    else if ( getProcessState() == REQ_DONE &&
     

    4) \Socket\HttpResponse.cpp(169):
    /* BUG MET 21Jan02
    _hFile NOT INITIALIZED, USE _file INSTEAD
    !HttpUtil::ifModSince( _hFile, timeIfMod ) )
    */
    !HttpUtil::ifModSince( _file, timeIfMod ) )
     

    5) \Socket\HttpResponse.cpp(182):
    /* BUG MET 21Jan02
    _hFile NOT INITIALIZED, USE _file INSTEAD
    CloseHandle( _hFile );
    _hFile = INVALID_HANDLE_VALUE;
    */
    _file.close();
     
    6) \Socket\HttpResponse.cpp(196):
    /* BUG MET 21Jan02
    _hFile NOT INITIALIZED, GetFileSize( _hFile, NULL ) WILL FAIL
    REMOVED contentLength TEMP VARIABLE
    // set content type and length
    long contentLength = GetFileSize( _hFile, NULL );
    */
     

    7) \Socket\HttpResponse.cpp(205):
    /* BUG MET 21Jan02
    NO NEED TO CREATE TEMP contentLength IF WE USE _file.size() DIRECTLY
    addHeader( idParamContentLength, contentLength );
    */
    addHeader( idParamContentLength, _file.size() );
     

    8) \Socket\HttpResponse.h(43):
    /* BUG MET 21Jan02
    AFTER BUG FIXES, THIS IS NOW AN UNUSED CLASS MEMEBER
    HANDLE _hFile; // handle to file associated with response
    */
     

    9) \Socket\HttpUtil.h(65):
    /* BUG MET 21Jan02
    THESE SHOULD ALL BE LOWER CASE
    #define idParamContentLength "Content-Length"
    #define idParamLastModified "Last-Modified"
    #define idParamIfModifiedSince "If-Modified-Since"
    #define idParamContentType "Content-Type"
    */
    #define idParamContentLength "content-length"
    #define idParamLastModified "last-modified"
    #define idParamIfModifiedSince "if-modified-since"
    #define idParamContentType "content-type"

    GeneralRe: some bug fixesmemberJames Curran29 May '02 - 11:32 
    A few more.....
     
    The code frequently has "using namespace std;", which is bad enough in general, but here goes for the ultimate evil use: Inside headers for library functions!
     
    Properly, when one is writing a library for general use, you should fully qualify standard class:
     
    [code]
    class HttpRequest :
    public HttpBuffer
    {
    public:
     
    std::string _url;
    std::string _path;
    std::string _pathInfo;
    // :
    };[/code]
     
    If that gets too tedious, the next best option is to use a "using" declaration, but just within the exact scope needed
     
    [code]
    class HttpRequest :
    public HttpBuffer
    {
    public:
    using std::string; // affects only clas HttpRequest
    string _url;
    string _path;
    string _pathInfo;
    // :
    };[/code]
     

    It seems that the original author just didn't understand namespaces at all. The class StringUtil, which exist merely to group a collection of related functions, really should be a namespace.
     
    Further, the code above demostrates another problem: Leading underscores. Most identifiers with a leading underscore are reserved, one way or another, usually for the library writer or the compiler vender. Best to avoid them entirely in your own code. If you need an member indicator, use a leading "m_" or a trailing underscore.
     

     
    Truth,
    James
    GeneralRe: some bug fixesmemberrfmobile10 Oct '03 - 23:30 
    " It seems that the original author just didn't understand namespaces at all. The class StringUtil, which exist merely to group a collection of related functions, really should be a namespace."
     
    Perhaps the code was written at a time when namespace support was broken in MSVC.
     
    -rick
    GeneralRe: some bug fixesmemberJames Curran11 Oct '03 - 3:50 
    Namespace usage that simple has worked in VC since version 5 (1996). By 2000 (the date of the article), only very complex naespaces usage failed.
     
    Truth,
    James
    Questiona Suggestion ??memberPaul_Fallon@yahoo.no.spam.please.com27 Jan '01 - 20:25 
    Hi David,
    i was wondering is it not a bit dangerous having the HTTPBuffer stored as a string ??? I am only wondering will any '\0' in the http stream cause the stream to be truncated too early.
     
    let me know what you think,
     
    Pau Fallon
     

    Paul_Fallon@yahoo.no.spam.please.com
    AnswerRe: a Suggestion ??memberJames Curran29 May '02 - 11:13 
    A std::string is a certain number of characters. (ie, the length is a stored value) It is not terminated at a \0.
     
    Truth,
    James

    General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

    Permalink | Advertise | Privacy | Mobile
    Web02 | 2.6.130523.1 | Last Updated 9 May 2000
    Article Copyright 2000 by David Hubbard
    Everything else Copyright © CodeProject, 1999-2013
    Terms of Use
    Layout: fixed | fluid