|
FYI-
Microsoft provides FindMimeFromData(), a quasi-documented function for determining the MIME type by inspecting the first 256 bytes of file data. If you really need an accurate MIME type, you might want to try it when the registry lookup comes back empty. I was surprised at the number of common file types that are not documented, e.g. on our Windows 2003 server ".doc" was not included in the registry. Apparently IE uses this function, as I came across it when investigating why the values returned through registry lookup did not match those generated via IE.
HTH,
Eric Gilbertson
PSS Systems
|
|
|
|
|
Hi,
what do you think about the following optimisation, which is very usefull if thinking about uploading large files by a post command to the webserver.
Change
ReadResponse(...)
{
...
if ((nBufRemaining-nData) == 0)
{
nBufSize += nGrowBy;
LPBYTE pNewBuf = new BYTE[nBufSize];
memcpy(pNewBuf, request.m_pRawRequest, request.m_dwRawRequestSize);
delete [] request.m_pRawRequest;
request.m_pRawRequest = pNewBuf;
}
...
}
to
ReadResponse(...)
{
...
if ((nBufRemaining-nData) == 0)
{
if ((nContentLength != -1) && (nContentLength > nGrowBy))
{
if (nContentLength < 10 * 1024 * 1024)
nBufSize += nContentLength;
else
nBuffSize += nGrowBy
}
else
nBufSize += nGrowBy;
LPBYTE pNewBuf = new BYTE[nBufSize];
memcpy(pNewBuf, request.m_pRawRequest, request.m_dwRawRequestSize);
delete [] request.m_pRawRequest;
request.m_pRawRequest = pNewBuf;
}
...
}
This will decrease upload time for a 6MB File from 25 seconds to 2 seconds, by avoiding heavy usage of new allocation and copy of memory.
|
|
|
|
|
The following bug prevents you from serving directory with spaces inside
after this small modification it works very well:
In CHttpDirectory::TransmitDirectory change
sLine.Format(_T("<tr>\r\n<td><a href=\%s\>...
to
sLine.Format(_T("<tr>\r\n<td><a href=\"%s\">...
Regarding the two " encapsulating the %s. By the way this is more W3c conform.
But PJ good job. Go on...
|
|
|
|
|
A bug in the CThreadPoolServer class crashes your application if using extension dlls. The original typedef of the function pointer for CreateWaitableTime and SetWaitableTimer missing the calling convention. Think you are lucky if you do not run in the same bug using the original source by including cpp and h files.
The correct version must be
typedef HANDLE
(WINAPI *lpfnCreateWaitableTimer)(LPSECURITY_ATTRIBUTES, BOOL, LPCTSTR);
typedef BOOL
(WINAPI *lpfnSetWaitableTimer)(HANDLE, const LARGE_INTEGER*, LONG, PTIMERAPCROUTINE, LPVOID, BOOL);
in CThreadPoolServer class.
|
|
|
|
|
I think that there is a bug in CHttpCGI::ReadFromClientStdout of HttpCGI.cpp of W3Mfc 1.72. The problem lies when the CGI output is very big. The output is the following:
HTTP/1.0 200 OK
datadatadatadatadatadataHTTP/1.0 200 OK datadatadatadatadatadatadatadatadataHTTP/1.0 200 OK and so on
In other words, some HTTP/1.0 200 OK are sent in the middle of the transaction.
Here is the fix:
In CHttpCGI::ReadFromClientStdout
1. Remove:
bFirstBuffer = FALSE;
2. Replace twice:
if (!bFoundHTTPReturnCodeLine)
by:
if (!bFoundHTTPReturnCodeLine && bFirstBuffer)
3. - Add at the end of the while loop
bFirstBuffer = FALSE;
The while loop then becomes:
while (bMore)
{
DWORD dwRead;
if (!ReadFile(hChildStdout, pszBuf, pSettings->m_dwCGIResponseBufferSize-1, &dwRead, NULL) || dwRead == 0)
bMore = FALSE;
else
{
//Used as a return value to indicate how much was sent to the client
dwDataSent += dwRead;
BOOL bFoundHTTPReturnCodeLine = FALSE;
if (bFirstBuffer)
{
//NULL terminate the data (so that we can use strstr)
pszBuf[dwRead] = '\0';
//See if the "Connection: Keep Alive" is being transmitted
bFoundKeepAlive = (strstr(pszBuf, "Connection: Keep-Alive") != NULL);
if (bFoundKeepAlive)
{
//Note it is important that "Content-Length" be also sent when using keep alives
//as otherwise client browsers do not know when to stop reading to get the end
//of the first response
bFoundKeepAlive = (strstr(pszBuf, "Content-Length: ") != NULL);
}
//Do we have a HTTP return code line
bFoundHTTPReturnCodeLine = (strstr(pszBuf,"HTTP/") != NULL);
//We only do this parse on the first buffer
}
//Send the data back down the socket
try
{
char* pszTTPReturnCodeLine = "HTTP/1.0 200 OK\n";
#ifdef W3MFC_SSL_SUPPORT
if (!bFoundHTTPReturnCodeLine && bFirstBuffer)
pClient->m_Socket.SendWithRetry(pszTTPReturnCodeLine, strlen(pszTTPReturnCodeLine), pSettings->m_dwWritableTimeout, pClient->m_SSL);
pClient->m_Socket.SendWithRetry(pszBuf, dwRead, pSettings->m_dwWritableTimeout, pClient->m_SSL);
#else
if (!bFoundHTTPReturnCodeLine && bFirstBuffer)
pClient->m_Socket.SendWithRetry(pszTTPReturnCodeLine, strlen(pszTTPReturnCodeLine), pSettings->m_dwWritableTimeout);
pClient->m_Socket.SendWithRetry(pszBuf, dwRead, pSettings->m_dwWritableTimeout);
#endif
}
catch(CWSocketException* pEx)
{
//Report the error
CString sError;
sError.Format(_T("CHttpCGI::ReadFromClientStdout, Failed to send to socket, Error:%d"), pEx->m_nError);
pClient->m_pServer->OnError(sError);
pEx->Delete();
bMore = FALSE;
}
}
bFirstBuffer = FALSE;
}
Gregoire
|
|
|
|
|
Hello PJ,
Great job. Fast question, how do you use the ISAPIMap ini settings. Looking through the source I can tell that it's something like ext=???, the ext being the file extension but I'm not sure what you are looking for it to be equal to.
Also, to make an MFC extension do I set the defines: W3MFC_EXT_CLASS, THRDPOOL_EXT_CLASS and SOCKMFC_EXT_CLASS to __declspec(dllexport)
p.s. Keep the Observatory progress pics coming, the're great.
Thanks
Rick Gordon
|
|
|
|
|
ISAPIMap: Just create a section of the form:
[ISAPIMap]
.someext=c:\somedirectory\isapidll1.dll
.someext=c:\anotherdir\isapidll2.dll
Note this is not required if you will be using the ISAPI dll path directly in a URL.
MFC Extension: See MFC Technote 33 on how to export functions from a DLL. This also points out the problems that AFX_EXT_CLASS has. This is the reason why I use my own defines.
Observatory pics: More on the way today or tomorrow!!
|
|
|
|
|
How do I found RFC 2045 document in codeproject.com?
Thansk.
|
|
|
|
|
As outlined in the documentation which I supply with the code, just use any search engine using the words RFC and 2045. For example http://www.ietf.org/rfc/rfc2045.txt
|
|
|
|
|
1st of all, thanks very PJ, much for your contributions !
Great quality !
I downloaded your latest VFWGrab 1.05 from you Web site,
build it, works fine.
Now if I minimize the main window, the picture stays the same...
(I use IncrementFilename and PeriodicInterval)
When I Maximize, pictures are updated again.
Is it a WebCam driver problem ?
Can I force an acquisition when minimized ?
Thanks for the help !
Patrick
|
|
|
|
|
Could be a webcam driver problem but I'd suspect it is an interaction with how user32 draws minimized windows, If you think about it there is no need to update the client area of a window which is minimized. A few ideas, play around with the OnPaint handler and DefWindowProc to see if you can fool it into drawing, otherwise I'd suggest you modify the code to hide the window or something like that rather than allow it to be minimized (at least when you want to capture). Another idea to avoid this problem would be to look into DirectShow which I'd be pretty confident does not have this problem as it is not based on use a HWND!.
|
|
|
|
|
He PJ
Thanks for the directions !
I tried OnPaint, then OnCmdMsg ..
just to find that I was notified anyway for every update request !
Then I looked at your code, and found there, an easy solution:
void CMainFrame::OnFileCapture()
{
// kick the webcam in case it needs it
// the main window could be minimized,
// or the screen saver be turned on....
BOOL ok = m_wndCap.GrabFrame();
Et voila !
Cheers
Patrick
|
|
|
|
|
has anybody implemented http 1.1 functionality???
thx
|
|
|
|
|
The 2 main features of HTTP/1.1 over 1.0 are just:
- Virtual hosting using the HOST header, i.e. having more than 1 domain managed on a single computer. This is the main reason all the web servers are 1.1 compliant, and why today a HTTP/1.0 browser can hardly browse more than 1% of the web.
- The Keep-Alive feature allows a client and a server to process several requests with one single socket connection. Really worth it, when you know that a single web page often means tens of http requests.
|
|
|
|
|
Just downloaded the latest version. Thanks PJ
"When a friend hurts us, we should write it down in the sand, where the winds of forgiveness get in charge of erasing it away, and when something great happens, we should engrave it in the stone of the memory of the heart, where no wind can erase it" Nish on life [methinks]
"It's The Soapbox; topics are optional" Shog 9
|
|
|
|
|
You always do great classes thx
|
|
|
|
|
I compiled it and can't seem to get it to work. It just says web server is starting. Am I doing something wrong? I am running Windows XP on NTFS with the Unicode version.
-Matt Newman
-Matt Newman
|
|
|
|
|
First make sure you have the latest version from my web site at www.naughter.com
|
|
|
|
|
well i found a bug you cant download two files simultaneously with this server try downloading 2 big files off your computer and you will know what i mean. i think the reason is non threading of the function called TransmitFile in CHttpClient please update the source code or email me a way to cure this thing i would be ver gratefull
Varun Shoor
plotoders@yahoo.co
|
|
|
|
|
The latest version on my web site implement an IOCP based thread pool so no more probs like the one you reported.
|
|
|
|
|
Hi, Codegurus around the world.
Since I'm looking for the web server source code,
I so appriciate for this code.
If someone want to take a test of your html, we can
use W3MFC.
To do this,
1) Change the connection setting to LAN in Internet options. (IE)
2) Type http://localhost:90 or http://localhost:90/index.html or htm
(if you use port number as 90 in the source code.)
Generally speaking, we use 8080. 80 is a default port of
the web server.
I often use FrontPage98's tiny web server, but now
I got my toy to the web stuff.
Have a nice day.
-Masaaki Onishi
|
|
|
|