You can subscribe to this list here.
2005 |
Jan
(2) |
Feb
(43) |
Mar
(83) |
Apr
(52) |
May
(7) |
Jun
|
Jul
(7) |
Aug
(2) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
---|
From: Vassilis P. <pa...@ya...> - 2005-04-30 18:02:29
|
I was looking at the code yesterday and I noticed the changes that had been made in send_file, when there was the problem with the file size. I saw that the server dynamically allocates req->size memory (WITHOUT checking for errors ) and then sends it all in one go. This approach is wrong for a number of reasons: 1. req->size may be really big. If we want to serve a file 100MB big (which is a realistic scenario), this means we should allocate a 100MB variable. Problems: The machine we're running on may not have 100MB RAM, and to boot, even if it does, how many concurrent 100MB requests can we serve? Few. 2. No error checking was performed and it is extremely likely to fail, given the size of the memory we may ask for. 3. Dynamic allocation is slow. Checking whether the memory was allocated adds one more if() test. I fixed the problem and now everything should be faster than before and more robust. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Jason C. <ja...@jc...> - 2005-04-30 10:33:07
|
On Saturday 30 April 2005 00:14, Vassilis Pandis wrote: > Jason, > Congratulations! I wish you and your partner a wonderful life. > I've been trying to make out what OT stands for for 10 minutes and I > can't find anything. > > Pandis OT = Off Topic. Used on mail list so people know it has nothing to do with the list per say. J. -- ja...@jc... Fortune: The British are coming! The British are coming! |
From: Vassilis P. <pa...@ya...> - 2005-04-29 23:15:02
|
Jason, Congratulations! I wish you and your partner a wonderful life. I've been trying to make out what OT stands for for 10 minutes and I can't find anything. Pandis --- Jason Corcoran <ja...@jc...> wrote: > Just found out myself and my partner are having twins !! > > We are over the moon we were told that we may not be able to have > kids. > > > I know this is OT but I am soooooo over the moon it is unbelivable. > > J. > > -- > ja...@jc... > > Fortune: > FLASH! > Intelligence of mankind decreasing. > Details at ... uh, when the little hand is on the .... > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great > events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play > to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > Kritton-devel mailing list > Kri...@li... > https://lists.sourceforge.net/lists/listinfo/kritton-devel > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Jason C. <ja...@jc...> - 2005-04-29 20:42:54
|
Just found out myself and my partner are having twins !! We are over the moon we were told that we may not be able to have kids. I know this is OT but I am soooooo over the moon it is unbelivable. J. -- ja...@jc... Fortune: FLASH! Intelligence of mankind decreasing. Details at ... uh, when the little hand is on the .... |
From: Vassilis P. <pa...@ya...> - 2005-04-29 12:03:14
|
The HTTP/1.1 specification states that servers should accept requests in the form of: GET http://localhost/index.html HTTP/1.1 Host: localhost HTTP/1.1 clients do not send such requests, but in the future all requests will be not by pathname, but by URI. Still, the Host: part of the header is required for HTTP/1.1 clients. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Vassilis P. <pa...@ya...> - 2005-04-29 11:27:38
|
A line should be taken to ensure that the server behaves correctly depending on whether the client has issued a HTTP/1.0 request or a HTTP/1.1 request. The small changes now make Kritton read the HTTP version from the client. Changes were also made to the determine_virtual_host so that a 400 error is issued when HTTP/1.1 client doesn't specify a Host: field in the header. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Vassilis P. <pa...@ya...> - 2005-04-27 14:37:46
|
Not much, just fixed the fact that when using a HEAD request on a directory, the message body was sent as well. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Jason C. <ja...@jc...> - 2005-04-26 20:46:13
|
This is what I get .... $ cvs update -Pd cor...@cv...'s password: Permission denied, please try again. cor...@cv...'s password: ? .tm_project.cache ? kritton ? kritton.prj ? kritton.pws ? temp.log cvs update: Updating . P Changelog M config.h RCS file: /cvsroot/kritton/kritton/main.c,v retrieving revision 1.11.4.22 retrieving revision 1.11.4.25 Merging differences between 1.11.4.22 and 1.11.4.25 into main.c rcsmerge: warning: conflicts during merge cvs update: conflicts found in main.c C main.c cvs update: Updating html cvs update: Updating html/errorpages P html/errorpages/400.html P html/errorpages/403.html P html/errorpages/404.html P html/errorpages/408.html P html/errorpages/414.html P html/errorpages/500.html P html/errorpages/501.html P html/errorpages/505.html cvs update: Updating html/html cvs update: Updating html/html/blah U html/html/blah/form.html U html/html/blah/form2.html cvs update: Updating html/html/blah/bob cvs update: Updating misc cvs update: Updating misc/logos cvs update: Updating misc/samples cvs update: Updating misc/samples/config cvs update: Updating misc/samples/scripts cvs update: Updating tools $ cat CVS/Tag TDEVELOPMENT Jason -- ja...@jc... Fortune: Don't shout for help at night. You might wake your neighbors. -- Stanislaw J. Lem, "Unkempt Thoughts" |
From: Nigel H. <nj...@ba...> - 2005-04-26 20:34:44
|
On Tue, 2005-04-26 at 12:24, Jason Corcoran wrote: > On Mon, Apr 25, 2005 at 09:26:05PM +0100, Nigel Horne wrote: > > How can I be sure, when doing "cvs update -Pd" that I've got the correct > > code? I did that but nothing seems new :-( > > > > -Nigel > > > Before you do the update try doing a diff cvs diff --brif this will give you the names of the files in CVS that diff from you source. Also have you modified any files in your workarea? > > If so you will need to do a cvs update -PdC this tells cvs to copy your files and overwrite with the ones in cvs. Also check that you have the correct branch checked out ( cat the CVS/tag file ) and make sure it is the correct branch. [njh@njh kritton]$ cvs update -PdC nig...@cv...'s password: ? Makefile.njh ? kritton cvs update: Updating . cvs update: Updating html cvs update: Updating html/errorpages cvs update: Updating html/html cvs update: Updating html/html/blah cvs update: Updating html/html/blah/bob cvs update: Updating misc cvs update: Updating misc/logos cvs update: Updating misc/samples cvs update: Updating misc/samples/config cvs update: Updating misc/samples/scripts cvs update: Updating tools [njh@njh kritton]$ cat CVS/tag cat: CVS/tag: No such file or directory [njh@njh kritton]$ > Jason. |
From: Jason C. <ja...@jc...> - 2005-04-26 11:24:31
|
On Mon, Apr 25, 2005 at 09:26:05PM +0100, Nigel Horne wrote: > How can I be sure, when doing "cvs update -Pd" that I've got the correct > code? I did that but nothing seems new :-( > > -Nigel Before you do the update try doing a diff cvs diff --brif this will give you the names of the files in CVS that diff from you source. Also have you modified any files in your workarea? If so you will need to do a cvs update -PdC this tells cvs to copy your files and overwrite with the ones in cvs. Also check that you have the correct branch checked out ( cat the CVS/tag file ) and make sure it is the correct branch. Jason. -- ja...@jc... Fortune: A working program is one that has only unobserved bugs. -- Murphy's Laws of Computer Programming |
From: Vassilis P. <pa...@ya...> - 2005-04-25 23:40:47
|
I'm not sure if cvs update -Pd is ok, but I use "cvs update -r DEVELOPMENT" and I always can see the latest changes (in all files + dirs). To double check whether there have been any changes or not, I do a "cvs log main.c" which will show me the history of main.c. Pandis --- Nigel Horne <nj...@ba...> wrote: > How can I be sure, when doing "cvs update -Pd" that I've got the > correct > code? I did that but nothing seems new :-( > > -Nigel > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Kritton-devel mailing list > Kri...@li... > https://lists.sourceforge.net/lists/listinfo/kritton-devel > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Nigel H. <nj...@ba...> - 2005-04-25 20:26:10
|
How can I be sure, when doing "cvs update -Pd" that I've got the correct code? I did that but nothing seems new :-( -Nigel |
From: Vassilis P. <pa...@ya...> - 2005-04-25 14:50:56
|
Hi, i'm back and took a look at your commit. Implementing POST is a very important step (probably after we have POST working we'll release Kritton properly to the world). I don't get however what exactly you are trying to do. If I have understood correctly, we have a string like "?foo=2&bar=red" and we want to create two arrays with foo, bar in one and 2, red in the second. If this is the case then I can see how this can be done simpler. What about the validity check? The problem you have with the % is universal to Kritton. It should be taken care of at some point. Instead of using malloc()s, which are slow and may be bug prone, why not use pointers ? void get_parmams_from_buffer(char *buffer,struct client_data *req) { char *p = strchr(buffer,'?'); if (p==NULL) { put_log(LOG_DEBUG_INFO,"No parameters detected."); } else { p++; get_couples_from_params(p,req) } } This will call get_couples_from_params() with a pointer to the string with the variables. Then you run a loop to read the variables and their values and create a list of pointers that point to them in the buffer string, avoiding the need for even one malloc (of course, it is a tacit agreement that we do not modify buffer in a way that would make these pointers invalid ). Anyway, if this approach seems a little too weird for you, tell me what has to be done exactly and when I find some time to spare (exams pending) I'll implement it. Because as far as I know in GET requests we don't need a message body from the client, it is up to the function that will handle POST to receive it. ie. when writing handle_method_post(), there should be another block of recv(), similar to the one in serve(). Pandis --- Florent Morel <fl...@fr...> wrote: > > Hi team, > > 1) getting the parameters > I worked on the get_param function this week and i commited it on > CVS. > > there are 3 functions : get_params, get_couple_from_params and > check_couples. > They all are in main.c, would it be useful to have it elsewhere ? > > - get_params : get the characters placed after "?" in the URL > (?var1=val1&var2=val2) > - get_couple_from_params : extract the couples from the params > - check_couple : check the couples syntax. > > Questions : > - How many params do we have to take care of ? (in my code, > max_params=5). > Note : I have a bug if the numbers of params in the URL is higher > than > max_params, nothing happens. > - To store the couples, i use a char *couple[max_params], would it be > better > with a char **couple ? > > - In check_couple : there is a list of allowed characters. It is to > be > completed. I still have troubles with characters like : "%2F". > > > I think that's all for now, please note that this code is a first try > to take > care of the parameters stored in the URL. It _needs_ some > optimisation and > verification (especially for the malloc). > > Give me your opinion/corrections... > > > 2) The POST method > > I read that when a Post method is sent by a client, the request looks > like : > [HEADER > containing a Content-length] > CRLF > [BODY > containing the params > i.e : var1=val1&var2=val2] > > My problem is that i cannot mange to get the whole request from the > client. So > i cannot get the parameters sent by the POST method. Any clue ? > > Regards, > Florent > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Kritton-devel mailing list > Kri...@li... > https://lists.sourceforge.net/lists/listinfo/kritton-devel > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Florent M. <fl...@fr...> - 2005-04-24 09:53:45
|
Hi team, 1) getting the parameters I worked on the get_param function this week and i commited it on CVS. there are 3 functions : get_params, get_couple_from_params and check_couples. They all are in main.c, would it be useful to have it elsewhere ? - get_params : get the characters placed after "?" in the URL (?var1=val1&var2=val2) - get_couple_from_params : extract the couples from the params - check_couple : check the couples syntax. Questions : - How many params do we have to take care of ? (in my code, max_params=5). Note : I have a bug if the numbers of params in the URL is higher than max_params, nothing happens. - To store the couples, i use a char *couple[max_params], would it be better with a char **couple ? - In check_couple : there is a list of allowed characters. It is to be completed. I still have troubles with characters like : "%2F". I think that's all for now, please note that this code is a first try to take care of the parameters stored in the URL. It _needs_ some optimisation and verification (especially for the malloc). Give me your opinion/corrections... 2) The POST method I read that when a Post method is sent by a client, the request looks like : [HEADER containing a Content-length] CRLF [BODY containing the params i.e : var1=val1&var2=val2] My problem is that i cannot mange to get the whole request from the client. So i cannot get the parameters sent by the POST method. Any clue ? Regards, Florent |
From: Vassilis P. <pa...@ya...> - 2005-04-17 19:41:58
|
Hi all, Ok, this is a short summary of the things I managed to do over the weekend: - Filename security is verified. Ie filenames beginning with ./ or ../ are not allowed. During the rewrite I had left this out because I wasn't sure whether it is allowed by the HTTP/1.1 protocol, but it is after all. - recv() is now in a loop, as it should be, until a CRLFCRLF is received. I admit that the loop can be optimized, because strstr() on the whole string is not the most efficient way to do this, but I can't see right now an elegant way of doing this, so, lacking time, I leave it for later. I'm leaving in a couple of hours for the airport. Have a very nice week and if possible, manage to code something (if you're sure it's ok, commit to CVS and post to group, if not, I'll be back on Saturday so I will be able to go through your code ) :) Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Vassilis P. <pa...@ya...> - 2005-04-16 09:57:06
|
--- Jason Corcoran <ja...@jc...> wrote: > On Fri, Apr 15, 2005 at 02:05:47PM +0200, Florent Morel wrote: > > > To sum it up, a TODO list would currently look > > > like this: > > > > > > - Extensive bug hunting, and fixing > > > - POST support > > > - Fix bug 1179831 > > > I'll take this one. (The bug? Sorry, I didn't understand ) Regarding the send() issue I still feel I'm right. send() returns the number of bytes sent because it is possible for send() to send less bytes than was required, without an error occuring. It has to do with the internals of the send() implementation (I conjecture it's a TCP buffer issue but frankly, I don't know why this is so). This means that send() should be ran in a loop to make sure that the entire buffer gets sent. In the same manner, recv() won't always receive all that data the client sends, you should run it in a loop (I'm planning on implementing this when I find a couple of minutes to spare). Just a request on style. Could we try to avoid mixed-case variables? The rest of the code hardly uses any mixed-case variables (none come to mind) so let's try to keep it consistent. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Jason C. <ja...@jc...> - 2005-04-15 12:19:35
|
On Fri, Apr 15, 2005 at 02:05:47PM +0200, Florent Morel wrote: > > To sum it up, a TODO list would currently look > > like this: > > > > - Extensive bug hunting, and fixing > > - POST support > > - Fix bug 1179831 I'll take this one. Jason. --=20 ja...@jc... Fortune: A hardware failure will cause system software to crash, and the customer = engineer will blame the programmer.=20 -- Murphy's Laws of Computer Programming n=B05 |
From: Florent M. <fl...@fr...> - 2005-04-15 12:05:52
|
> To sum it up, a TODO list would currently look > like this: > > - Extensive bug hunting, and fixing > - POST support > - Fix bug 1179831 > - Improve logging. Make it simpler and more comprehensible (ie. less > LOG_*) defines. More *useful* logging. > I'll work on the POST support, as i already began to implement the "get_params" method. I give you some news later. bye florent > I did a CVS commit that fixes some HEAD issues and added the emergency > handling functions. > I feel that when the above have been accomplished, Kritton promotion > must begin. Do you think that in the meantime we should release and > keep the 0.5 as development releases ? > > Pandis > |
From: Jason C. <ja...@jc...> - 2005-04-15 08:38:04
|
On Thu, Apr 14, 2005 at 10:40:21PM +0100, Vassilis Pandis wrote: >=20 > Ok, nice work on finding the problem. Actually, send() was usually > called once. However, send may NOT send all the files, and will return > the number of bytes sent. The application must make sure that all bytes > have been sent, by using send() inside a loop. I'll commit the fix's > fix on Saturday probably. >=20 >=20 If you look at the send command it is set to send the size of the file. I= f it dose not there is a system problem and an error sould be logged. You= could end up in an indefinite loop if oyou are trying to send say 100 by= tes and it only sends 20 and you sit in the loop until the counter =3D 10= 0 Jason. --=20 ja...@jc... Fortune: Program complexity grows until it exceeds the capabilities of the program= mer who must maintain it.=20 -- Murphy's Laws of Computer Programming n=B013 |
From: Vassilis P. <pa...@ya...> - 2005-04-14 21:40:35
|
Ok, nice work on finding the problem. Actually, send() was usually called once. However, send may NOT send all the files, and will return the number of bytes sent. The application must make sure that all bytes have been sent, by using send() inside a loop. I'll commit the fix's fix on Saturday probably. --- Jason Corcoran <ja...@jc...> wrote: > I have checked in the fix for the jpgs. > > I have checked it against Firefox konqueror dillo and IE running on a > Mandrake > 10 and FC 3 server. > > > As a point this fix will speed up things, as instead of a few sends > there is > only one send per transmit. > > Jason > -- > ja...@jc... > > Fortune: > Time goes, you say? > Ah no! > Time stays, *we* go. > -- Austin Dobson > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Kritton-devel mailing list > Kri...@li... > https://lists.sourceforge.net/lists/listinfo/kritton-devel > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Jason C. <ja...@jc...> - 2005-04-14 20:14:06
|
I have checked in the fix for the jpgs. I have checked it against Firefox konqueror dillo and IE running on a Mandrake 10 and FC 3 server. As a point this fix will speed up things, as instead of a few sends there is only one send per transmit. Jason -- ja...@jc... Fortune: Time goes, you say? Ah no! Time stays, *we* go. -- Austin Dobson |
From: Vassilis P. <pa...@ya...> - 2005-04-14 16:12:13
|
Hi guys, I will be abroad from monday to friday and will be unable to follow the development process. To sum it up, a TODO list would currently look like this: - Extensive bug hunting, and fixing - POST support - Fix bug 1179831 - Improve logging. Make it simpler and more comprehensible (ie. less LOG_*) defines. More *useful* logging. I did a CVS commit that fixes some HEAD issues and added the emergency handling functions. I feel that when the above have been accomplished, Kritton promotion must begin. Do you think that in the meantime we should release and keep the 0.5 as development releases ? Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Florent M. <fl...@fr...> - 2005-04-14 11:38:03
|
On Thursday 14 April 2005 05:10, kri...@li... wrote: > Well, I thought of that too, but I don't see the point of having the > Kritton version in the errorpage. I mean, the client doesn't really > care if it's Kritton 0.5.1 compiled with syslogging or if it's Kritton > 0.5.2 with the default compilation options. > Actually, this may be > considered a downside since the more information we handle out to the > client, the more vulunerable Kritton becomes ( a bug affecting 0.5.3 > but not other versions will pose a threat when the client knows that > it's communicating with 0.5.3 eh ! i didn't think about that point, i have to say it's a good one ;o). > - similarly if there is a bug present > only in the syslog logging, it would be nice if the user doens't know > that this specific Kritton was compiled with syslog support). > Of course we have to satisfy user curiosity. I'm suggesting that only > v0.5 , v2.3, v1.0 is shown, without any other information about the > compilation options. > What about the page design? Any changes to suggest? simplest is the best, and that ones are pretty simple. bye > > Pandis |
From: Vassilis P. <pa...@ya...> - 2005-04-13 13:45:10
|
Well, I thought of that too, but I don't see the point of having the Kritton version in the errorpage. I mean, the client doesn't really care if it's Kritton 0.5.1 compiled with syslogging or if it's Kritton 0.5.2 with the default compilation options. Actually, this may be considered a downside since the more information we handle out to the client, the more vulunerable Kritton becomes ( a bug affecting 0.5.3 but not other versions will pose a threat when the client knows that it's communicating with 0.5.3 - similarly if there is a bug present only in the syslog logging, it would be nice if the user doens't know that this specific Kritton was compiled with syslog support). Of course we have to satisfy user curiosity. I'm suggesting that only v0.5 , v2.3, v1.0 is shown, without any other information about the compilation options. What about the page design? Any changes to suggest? Pandis --- Florent Morel <fl...@fr...> wrote: > > Hi team, > > id' like to say a few things about the new errorpages : > > - Some punctuation problems (need a 'blank' - " " - after a "," or a > "."). > Pretty little point, but these pages are what the users are going to > see, so > we have to do it the best we can. > - Would be nice if we could have some infos about kritton on the > pages > (version, some options when compiled... see apache pages, you'll know > what i > mean.). > > For this point, i suggest that, instead of having the pages > hard-written, we > can build them at compile time and having more infos displayed on the > pages. > That would also be interesting for every page (example : the home > page) where > we have informations that can be different between two releases. > > I can do this task (write the code to build the pages at > compile-time) if you > find it useful. > > Tell me. > > florent > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Kritton-devel mailing list > Kri...@li... > https://lists.sourceforge.net/lists/listinfo/kritton-devel > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Florent M. <fl...@fr...> - 2005-04-13 12:06:01
|
Hi team, id' like to say a few things about the new errorpages : - Some punctuation problems (need a 'blank' - " " - after a "," or a "."). Pretty little point, but these pages are what the users are going to see, so we have to do it the best we can. - Would be nice if we could have some infos about kritton on the pages (version, some options when compiled... see apache pages, you'll know what i mean.). For this point, i suggest that, instead of having the pages hard-written, we can build them at compile time and having more infos displayed on the pages. That would also be interesting for every page (example : the home page) where we have informations that can be different between two releases. I can do this task (write the code to build the pages at compile-time) if you find it useful. Tell me. florent |