libcgi-general — All purpose list. Focus are all related subjects to LibCGI,.

Re: [Libcgi-general] Premature end of script headers

[Tonu S. <to...@pl...>]

On Thu, 2003-01-23 at 13:46, Rafael Steil wrote:
>=20
> 	I need to revise cgi_end().. for now, the only thing it does is free=20
> cookies and session vars from memory.. not a big issue. In future release=
s,=20
> cgi_end() intention is to make a complete memory cleanup, but to do that =
we need
> memory management functions before. So, comment the call to this funciton=
 and
> be happy :)

I have it!

I do not remember what exact version is in CVS right now but I use it
in-house for some time already. SourceForge project "dbug" is it.

Today I am very sleepy but I can revise it some other day.

  T=F5nu

Re: [Libcgi-general] Premature end of script headers

[Rafael S. <ra...@in...>]

	I need to revise cgi_end().. for now, the only thing it does is free 
cookies and session vars from memory.. not a big issue. In future releases, 
cgi_end() intention is to make a complete memory cleanup, but to do that we need
memory management functions before. So, comment the call to this funciton and
be happy :)

	Java Servlets stays in memory and the GC does the hard job of memory
management. You can think cgi_end() as being destroy() method from HttpServlet.

Rafael

On 22 Jan 2003 17:34:22 -0500
meb <mbe...@mi...> wrote:

> 0.8.1 is the libcgi version and I'm using rh7.3 with apache 1.3.23.
> I'm also linking against libmysql 10.0.0 and libmaildir from maildrop
> 1.5.1
> 
> "well, you can give it away"
> does this mean that omitting cgi_end() is safe? it would seem to me that
> with a cgi which is a short lived process that memory cleanups aren't
> that import because as soon as it returns the os will clean it up?
> unlike java servlets which never return.
> On Wed, 2003-01-22 at 14:46, Rafael Steil wrote:

Re: [Libcgi-general] Premature end of script headers

[meb <mbe...@mi...>]

0.8.1 is the libcgi version and I'm using rh7.3 with apache 1.3.23.
I'm also linking against libmysql 10.0.0 and libmaildir from maildrop
1.5.1

"well, you can give it away"
does this mean that omitting cgi_end() is safe? it would seem to me that
with a cgi which is a short lived process that memory cleanups aren't
that import because as soon as it returns the os will clean it up?
unlike java servlets which never return.
On Wed, 2003-01-22 at 14:46, Rafael Steil wrote:
> 	Ugh.. cgi_end() sucks.. well, you can give it away, the function
> intention is just to do some memory cleanups and other things relacted.
> You could help informing which version of LibCGI are you using and the
> OS. 
> 
> Rafael
> 
> On Wed, 2003-01-22 at 16:29, meb wrote:
> > uh oh.
> > commenting out cgi_end() fixed it.
> > I can't get the error 400 anymore.
> > 
> > how bad is it to leave that out of my cgi.
> > is there any information you would like to locate the problem?
> > On Wed, 2003-01-22 at 14:14, Rafael Steil wrote:
> > 
> > thanks alot,
> > I am very satisfied with your library anyway.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Libcgi-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libcgi-general

Re: [Libcgi-general] Premature end of script headers

[Rafael S. <ra...@in...>]

	Ugh.. cgi_end() sucks.. well, you can give it away, the function
intention is just to do some memory cleanups and other things relacted.
You could help informing which version of LibCGI are you using and the
OS. 

Rafael

On Wed, 2003-01-22 at 16:29, meb wrote:
> uh oh.
> commenting out cgi_end() fixed it.
> I can't get the error 400 anymore.
> 
> how bad is it to leave that out of my cgi.
> is there any information you would like to locate the problem?
> On Wed, 2003-01-22 at 14:14, Rafael Steil wrote:
> 
> thanks alot,
> I am very satisfied with your library anyway.

Re: [Libcgi-general] Premature end of script headers

[meb <mbe...@mi...>]

uh oh.
commenting out cgi_end() fixed it.
I can't get the error 400 anymore.

how bad is it to leave that out of my cgi.
is there any information you would like to locate the problem?
On Wed, 2003-01-22 at 14:14, Rafael Steil wrote:

thanks alot,
I am very satisfied with your library anyway.
> 	So, the script goes to the end, and then you get and internall
> error, but *aparentely* all is fine.. that's it? Its complitaced to
> say exactly what could be causing this problem.. have you tried to 
> remove cgi_end() function call? Sometime ago, when I was developing some
> parts, cgi_end() did invalid pointer operations, which caused some
> memory faults.. try it, remove cgi_end() and tell us the result. 
> 
> Note, all is to work fine, but.... Another question: what version of
> libcgi are you using, and what is the OS ?
> 
> Rafael
> 
> On Wed, 2003-01-22 at 15:58, meb wrote:
> > I used a similar tactic, I would put stuff like this:
> > fprintf(stdout,"made it this far:4");
> > throughout the code, which prints the messages to apache's error log.
> > and the code executes successfully to the cgi_end() call
> > On Wed, 2003-01-22 at 12:03, Rafael Steil wrote:
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Libcgi-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libcgi-general

Re: [Libcgi-general] Premature end of script headers

[Rafael S. <ra...@in...>]

	So, the script goes to the end, and then you get and internall
error, but *aparentely* all is fine.. that's it? Its complitaced to
say exactly what could be causing this problem.. have you tried to 
remove cgi_end() function call? Sometime ago, when I was developing some
parts, cgi_end() did invalid pointer operations, which caused some
memory faults.. try it, remove cgi_end() and tell us the result. 

Note, all is to work fine, but.... Another question: what version of
libcgi are you using, and what is the OS ?

Rafael

On Wed, 2003-01-22 at 15:58, meb wrote:
> I used a similar tactic, I would put stuff like this:
> fprintf(stdout,"made it this far:4");
> throughout the code, which prints the messages to apache's error log.
> and the code executes successfully to the cgi_end() call
> On Wed, 2003-01-22 at 12:03, Rafael Steil wrote:

Re: [Libcgi-general] Premature end of script headers

[meb <mbe...@mi...>]

I used a similar tactic, I would put stuff like this:
fprintf(stdout,"made it this far:4");
throughout the code, which prints the messages to apache's error log.
and the code executes successfully to the cgi_end() call
On Wed, 2003-01-22 at 12:03, Rafael Steil wrote:
> 
> 	Well, well.. debug cgi application, even when they are written in perl, for example,
> are a bit complicate ( more than I would like ) to do. Your code may be segfaulting
> because some memory allocation problem somewhere, or another function you are calling
> may be sending output before cgi headers are send ( using cgi_init_headers() ).. well, 
> is impossible to guess.
> 	Here are some ways to try debug and find the error:
> 
> *) This is the most boring and hard to do, but usually works: in you code, #define some
> var to specify you want do debug:
> 
> #define DEBUG 1
> 
> Now, on the parts you guess the error may occur, put something like
> 
> #if DEBUG
> cgi_init_headers();
> puts("am here baby");
> exit(1);
> // the rest of code here
> #endif
> ...
> 
> if you see the ouput, then change to
> 
> #if DEBUG
> cgi_init_headers();
> puts("am here baby");
> 
> // the rest of code here
> puts("passes 'the rest of the code here'");
> exit(1);
> #endif
> 
> and try again.. if now the cgi breaks, so you have find here the bug is, and the could
> do something to fix it.
> 
> Of course this is really suck to do, and you need to suppose *where* the bug is.
> 
> 
> *) Go to http://log4c.sourceforge.net and the Log4C logging package for C, and then use
> it to put logs into your application.. when the cgi fail, just look to the logs and see
> where was the last log entry.. 
> 
> *) Try running for the command line. This one works fine and is the most simple to do,
> but you should use GET instead POST ( POST forms are dificult to reproduce ). For example,
> lets say you app waits to receive "name" and "email" as parameters. In the shell, do it:
> ( considering you are using Bash )
> 
> $ export QUERY_STRING='name=This+is+my+name&email=myemail'
> 
> Compile your cgi and then run it:
> 
> $ ./myCgi.cgi
> 
> If all worked fine, you will see the ouput, however, you may get a segfault, a library
> load error or any other kind of error. Basead on the results, you could find the error.
> 
> Well, this is the methods that I use, but I agree that isn't good. If you could post here
> some pieces of code you are using, this may help. Don't forget that many times the error
> is with another tool or function you are using.. 
> 
> Rafael
> 
> On 22 Jan 2003 04:10:50 -0500
> meb <mbe...@mi...> wrote:
> 
> > I have a cgi using libcgi.
> > I am new to c/cgi devel, my experience is with java servlets. I learned
> > during development that if it exits ungracefully it can cause "Premature
> > end of script headers" and an error 500, however now it does not seem to
> > do it in any predictable fashion and I know my program flows at least
> > all the way to cgi_end(). any help would be very appreciated, I am
> > admittedly not familiar with the platform I'm working with. My boss is
> > breathing down my neck.
> > 
> > -matt
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Libcgi-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libcgi-general

Re: [Libcgi-general] Premature end of script headers

[Rafael S. <ra...@in...>]

	Well, well.. debug cgi application, even when they are written in perl, for example,
are a bit complicate ( more than I would like ) to do. Your code may be segfaulting
because some memory allocation problem somewhere, or another function you are calling
may be sending output before cgi headers are send ( using cgi_init_headers() ).. well, 
is impossible to guess.
	Here are some ways to try debug and find the error:

*) This is the most boring and hard to do, but usually works: in you code, #define some
var to specify you want do debug:

#define DEBUG 1

Now, on the parts you guess the error may occur, put something like

#if DEBUG
cgi_init_headers();
puts("am here baby");
exit(1);
// the rest of code here
#endif
...

if you see the ouput, then change to

#if DEBUG
cgi_init_headers();
puts("am here baby");

// the rest of code here
puts("passes 'the rest of the code here'");
exit(1);
#endif

and try again.. if now the cgi breaks, so you have find here the bug is, and the could
do something to fix it.

Of course this is really suck to do, and you need to suppose *where* the bug is.


*) Go to http://log4c.sourceforge.net and the Log4C logging package for C, and then use
it to put logs into your application.. when the cgi fail, just look to the logs and see
where was the last log entry.. 

*) Try running for the command line. This one works fine and is the most simple to do,
but you should use GET instead POST ( POST forms are dificult to reproduce ). For example,
lets say you app waits to receive "name" and "email" as parameters. In the shell, do it:
( considering you are using Bash )

$ export QUERY_STRING='name=This+is+my+name&email=myemail'

Compile your cgi and then run it:

$ ./myCgi.cgi

If all worked fine, you will see the ouput, however, you may get a segfault, a library
load error or any other kind of error. Basead on the results, you could find the error.

Well, this is the methods that I use, but I agree that isn't good. If you could post here
some pieces of code you are using, this may help. Don't forget that many times the error
is with another tool or function you are using.. 

Rafael

On 22 Jan 2003 04:10:50 -0500
meb <mbe...@mi...> wrote:

> I have a cgi using libcgi.
> I am new to c/cgi devel, my experience is with java servlets. I learned
> during development that if it exits ungracefully it can cause "Premature
> end of script headers" and an error 500, however now it does not seem to
> do it in any predictable fashion and I know my program flows at least
> all the way to cgi_end(). any help would be very appreciated, I am
> admittedly not familiar with the platform I'm working with. My boss is
> breathing down my neck.
> 
> -matt

Re: [Libcgi-general] Premature end of script headers

[meb <mbe...@mi...>]

my flow looks like this:

setuid()
cgi_init()
cgi_session_start()
cgi_process_form()
cgi_init_headers()

print a bunch of crap, register some session vars


cgi_end()


is this correct?

[Libcgi-general] Premature end of script headers

[meb <mbe...@mi...>]

I have a cgi using libcgi.
I am new to c/cgi devel, my experience is with java servlets. I learned
during development that if it exits ungracefully it can cause "Premature
end of script headers" and an error 500, however now it does not seem to
do it in any predictable fashion and I know my program flows at least
all the way to cgi_end(). any help would be very appreciated, I am
admittedly not familiar with the platform I'm working with. My boss is
breathing down my neck.

-matt

Re: [Libcgi-general] some warnings

[Rafael S. <ra...@in...>]

	Done. The changes are in
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libcgi


Rafael

On Mon, 2003-01-20 at 17:58, Tonu Samuel wrote:
> Some annoying warnings removed from cgi.h ("blah blah, function is not
> prototype"). Patch included, please apply.
> 
>   Tõnu

[Libcgi-general] some warnings

[Tonu S. <to...@pl...>]

Some annoying warnings removed from cgi.h ("blah blah, function is not
prototype"). Patch included, please apply.

  T=F5nu

Re: [Libcgi-general] Expression evaluation

[Rafael S. <ra...@in...>]

	I am not sure about the use XSL. What I want is to be able to put some
"objects" into a context visible to the template and the make a parser
to parse it, writing the output to the browser or any other kind of text
file. For example, supporse I have a linked list with name=value pairs,
and then I want to display the values in some html page. Using
templates, will possible to do something like this:

// my_cgi.c
...
cgi_init();
cgi_template_context *context;
linked_list *list;
// malloc()'s memory etc etc..

list->add("name 1", "value 1");
list->add("name 2", "value 2");
list->add("name 3", "value 3");

// Puts the list in a context visible to the template
context->add("my_list", list);

// Do it
cgi_template_parse("my_template.html", context);
..


The file "my_template.html" looks like

...
<h3>Hello, the values in the list are:</3>
<table>
#foreach ($item in $my_list)
	<tr>
	<td>$item.name</td>
	<td>$item.value</td>
	</tr>
#end
</table>
...

and so on. ".name" and ".value" points to linked list's functions to get
the name and value of some item in the list.

But this is just a simple example of want I want, and in my opinion is
much more simple than XSL. Some days ago I written a document where are
a simple explanation: http://libcgi.sourceforge.net/templates.htm

Rafael

On Sun, 2003-01-19 at 08:25, Tonu Samuel wrote:
> IMHO you are reinventing the wheel. I express my own viewpoint (which is
> always right ;))
> 
> First I define "templates": Templates are way to put different data into
> standard layout. Templates are not meant for code.
> 
> To do this successfully, conditional expressions and loops are needed.
> And
> this what XSL exactly does. Additionally you get good level of
> standardization - there are a lot of tools and tutorials available.
> 
>   Tonu

Re: [Libcgi-general] Expression evaluation

[Tonu S. <to...@pl...>]

On Sun, 2003-01-19 at 00:09, Rafael Steil wrote:
> 
> 	Someone have code to evaluate expressions like math operations,
> condition checks ( to use in if(), while() etc.. ) ?
> 
> I want this to incorporate to the engine of the template system.. I have
> working code, but it isn't good.. :-\

IMHO you are reinventing the wheel. I express my own viewpoint (which is
always right ;))

First I define "templates": Templates are way to put different data into
standard layout. Templates are not meant for code.

To do this successfully, conditional expressions and loops are needed.
And
this what XSL exactly does. Additionally you get good level of
standardization - there are a lot of tools and tutorials available.

  Tonu

[Libcgi-general] Expression evaluation

[Rafael S. <ra...@in...>]

	Someone have code to evaluate expressions like math operations,
condition checks ( to use in if(), while() etc.. ) ?

I want this to incorporate to the engine of the template system.. I have
working code, but it isn't good.. :-\

Rafael

Re: [Libcgi-general] Re: libcgi bug + fix

[Tonu S. <to...@pl...>]

On Sun, 2003-01-12 at 15:31, Rafael Steil wrote:
> 	Well, if it will be more secure, then that's great. But an important
> question: will be compatible with older versions ( just the function
> names, not the manipulation method ) or users of the new version should
> rewrite code?=20

Not all users need such level of security. I think best option is to
make both options available. Old things remain and new ones come.

I probably want to write new functions for this but meanwhile I can
benefit from yours. For example I want some data related to session
survive between pageviews on server. This seems to be implemented
already in libcgi! This is why I do not want to start it from scratch
and want to merge our efforts.

> You mean, accessing the url by hand and then get access without
> authorization? Or that all users, after they were logged in, will have
> access to the same places?

Second option is closer.=20

> > I have working code. Need to clean it and merge with libcgi. Also I wan=
t
> > to add more examples using FastCGI.=20
> >=20
>=20
> I never have used FastCGI, but will read more about it.=20

There is a need to keep data structures in memory between pageviews.
When code is large and does a lot work before it can output data, this
makes it 10 or more times faster. Small and simple CGI programs do not
benefit too much.

I had case in own experience when PHP code took over second on each
pageview. After two days recoding same thing into C it runs without any
delay. There are different reasons why this happened but biggest win is
reusing data. I had to do a lot on SQL queries plus parse 1..2 megs of
XML and later used just some hundred bytes from all of this.=20
In C I kept parsed XML object in memory and access data I needed
directly by pointers.=20

In similar situations FastCGI rocks.

   T=F5nu

Re: [Libcgi-general] Re: libcgi bug + fix

[Rafael S. <ra...@in...>]

	Well, if it will be more secure, then that's great. But an important
question: will be compatible with older versions ( just the function
names, not the manipulation method ) or users of the new version should
rewrite code? 

>  Later HTML
> forms have field "action" where form directs flow from one page to
> another. This means malicious user can affect it and get into places he
> shouldn't be.
> 

You mean, accessing the url by hand and then get access without
authorization? Or that all users, after they were logged in, will have
access to the same places?

> I have working code. Need to clean it and merge with libcgi. Also I want
> to add more examples using FastCGI. 
> 

I never have used FastCGI, but will read more about it. 


Rafael

Re: [Libcgi-general] Re: libcgi bug + fix

[Tonu S. <to...@pl...>]

On Fri, 2003-01-10 at 21:23, Rafael Steil wrote:
> 	Two in a one single day?? come on, this way I will think that libcgi is
> a bug repository  :)

Actually three :).=20

Today I was thinking maybe it is right for community if we join our
efforts and I provide your library with totally different session
handling stuff.

The whole idea of mine is get away from "golden key" type session
handling. Most systems use it: user is authenticated once and provided
some singe "key" which is good for everything in future. Later HTML
forms have field "action" where form directs flow from one page to
another. This means malicious user can affect it and get into places he
shouldn't be.

I have working code. Need to clean it and merge with libcgi. Also I want
to add more examples using FastCGI.=20

About experience - I have been involved writing code for 17 years. While
not too strong in C, my code is incorporated in many apps including
MySQL.=20

  T=F5nu

[Libcgi-general] CVS access

[Rafael S. <ra...@in...>]

	I have created this night the cvs repository, now all the development
branches of libcgi will be there. For now, Tonu's fixes are commited. To
access the cvs, just point your browser to
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libcgi/ 

If you need instructions about how to use CVS, there are some
explanations at http://sourceforge.net/cvs/?group_id=2114. Check the
topic "Anonymous CVS Access". 

CVS howto can be located at http://cvsbook.red-bean.com/cvsbook.html. 

Another way to keep up to date is to get "CVS nightly tarball", found at
libcgi's sourceforge project page. 


Rafael

Re: [Libcgi-general] Re: libcgi bug + fix

[Rafael S. <ra...@in...>]

	Two in a one single day?? come on, this way I will think that libcgi is
a bug repository  :)

Well, speaking seriously, I'll enable CVS access at sourceforge, so we
can keep up to date. Probably tomorow the cvs repository will be up.

Thanks 
Rafael

On Fri, 2003-01-10 at 19:06, Tonu Samuel wrote:
> On Fri, 2003-01-10 at 17:25, Tonu Samuel wrote:
> > Hi!
> 
> One more bug found. There were consequent lines where one line free()-d
> variable and next one used it again. Fixed now.
> 
> 
> 
> ______________________________________________________________________

[Libcgi-general] Re: libcgi bug + fix

[Tonu S. <to...@pl...>]

On Fri, 2003-01-10 at 17:25, Tonu Samuel wrote:
> Hi!

One more bug found. There were consequent lines where one line free()-d
variable and next one used it again. Fixed now.

[Libcgi-general] libcgi bug + fix

[Tonu S. <to...@pl...>]

Hi!

I am using libcgi together with FastCGI. Investigating problem with
wrong program flow I finally found two bugs in libcgi code. One of them
is just kind of programmer bug which worked but still was bug. returning
some global variable (formvars_start) is not correct and has to be
*start instead.

Another bug was what I was searching for. FastCGI makes possible to
reuse CGI data structures. But libcgi had bug which leaded to improper
processing of query parameters. libcgi relies on content of
formvars_last on init which has to be cleared for this.

Tested for few minutes only but works for me. Maybe it is better to
rewrite parts of code using formvars_last.

   T=F5nu

[Libcgi-general] Template System

[Rafael S. <ra...@in...>]

Hi all, 
I'm starting to work in the implementation of a template engine for
LibCGI, and here is some definations I've been working today. Please
give you suggestions and comments. Maybe the idea of "Template Engine" (
or "Template System" ) is not clear for all, so if you have any doubt
about it, please ask. The intention is to make a simple and easy to use
system. 

http://libcgi.sourceforge.net/templates.htm

Rafael

[Libcgi-general] Coding standards and documentation

[Rafael S. <ra...@in...>]

	I placed at

http://libcgi.sourceforge.net/codeformatting.htm

a doc describing some conventions to write code and to document the
source. I still need to update the home page, but html sucks :)

Rafael

[Libcgi-general] Vesion 0.8.1 is out

[Rafael S. <ra...@in...>]

	I have released 0.8.1 version this weekend. The sourcecode tree is more
clean and intuitive, Solaris compilation problems were fixed and some
other bugs were fixed. The complete Changelog can be found at
http://libcgi.sourceforge.net/ChangeLog

Rafael