 |
|
 |
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?
|
|
|
|
 |
|
 |
You need to set the content type on the header so IE knows what to expect, it just defaults to TEXT/HTML
|
|
|
|
 |
|
 |
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.
|
|
|
|
 |
|
 |
When I often link same URL, server is very busy and CPU increase to 100% time.
How to decrease it?
|
|
|
|
 |
|
 |
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"
|
|
|
|
 |
|
 |
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
|
|
|
|
 |
|
 |
" 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
|
|
|
|
 |
|
 |
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
|
|
|
|
 |
|
 |
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
|
|
|
|
 |
|
 |
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
|
|
|
|
 |