bertrand-lupart / caudium Goto Github PK

What steps will reproduce the problem?
1. Install a brand new server
2. Send data < 65kB to the server using POST
3. Fails, unfriendly way

What is the expected output? What do you see instead?

- Expected at least a message in the server logs.
- User sees "connexion reset"
- 65kB is very few by the time going

What steps will reproduce the problem?
1. Install Caudium
2. Wait the cache to be sufficiently populated
3. See the error 500 from the cache coming


What is the expected output? What do you see instead?

No error 500 from the cache expected.


Please use labels and text to provide additional information.


Below's the backtrace from Debian's caudium 1.4.12

Couldn't open file /var/cache/caudium/cache/a1f6935accad89f2617e783324663449: 
Permission denied
/usr/lib/pike/7.6.112/modules/Stdio.pmod/module.pmod:1971: 
Stdio->write_file("/var/cache/caudium/cache/a1f6935accad89f2617e783324663449","/
* Storage.Disk */\n\nmapping data = ([ /* 3 elements */\n  \"key\": 
\"/f8dd53af15722e2b1b6b2c2a058126fa/meta\",\n  \"namespace\": \"Linkfirst 
VH"+[321],438)
etc/modules/Storage.pmod/Methods.pmod/Disk.pike:115: 
Storage.Methods.Disk()->store("Linkfirst VHS system 
SQL","/f8dd53af15722e2b1b6b2c2a058126fa/meta","\266ke0\1\b\6\6disk_cacheh\6\5ram
_cache\177\6\3expires\310L,\302\305\6\0hits\b'\6\4_mapping\177\6\0hash\6\34f8dd5
3af15722e2b1b6b2c2a058126fa\6\0type\6\4variable\6\2object!\6"+[86])
etc/modules/Storage.pmod/Manager.pike:140: Storage.Manager()->sync("Linkfirst 
VHS system SQL","/f8dd53af15722e2b1b6b2c2a058126fa/meta")
home/peter/hack/Pike/7.6-distmaker/src/backend.cmod:803: 
Pike.Backend(0)->`()(3600.000000)

What steps will reproduce the problem?
1. Unknown

What steps will fix the problem?
1. Stop the server
2. Clean up the cache
3. start the server

Some code of caudium.c has been commited in 1.4 (r5573) for handling empty
URL variables.

Check if that should be changed into 1.5 as well and add a a testsuite for
empty variables.

What steps will reproduce the problem?
1. load "Core RXML Tags" in a virtual server
2. try "<set variable="foo" expr="1+1"> &form.foo;"
3. try "<set variable="foo" expr="1 + 10"> &form.foo;"

What is the expected output? What do you see instead?

First should be 2, second 11.

Please use labels and text to provide additional information.

Bug resides in Caudium.sexpr_eval()

What steps will reproduce the problem?
1. Load the "XML-Compliant RXML Parser" module
2. Try to serve the following code: "<!-- This shouldn't break the parser --> 
Date should be here: 
<date>"
3. The date doesn't appear.

What is the expected output? What do you see instead?

The date should appear, but no RXML parsing is done after the single quote.

Please use labels and text to provide additional information.

1. Generate a key/certificate using the wizard, for the CIF for example. Name 
them cif_key.pem 
and cif_certificate.pem, bind them to a ssl3 port, say 22203.

2. Use the new certificate with Firefox 3 (CIF on TCP 22203)

3. Generate a key/certificate using the wizard, for your website for example. 
Name them 
web_key.pem and web_certificate.pem, bind them to a ssl3 port, say 443.

4. Use the second certificate with Firefox 3 (website on TCP 443)


Firefox 3 won't display the website, and display the following error:
sec_error_reused_issuer_and_serial with no way to circumvent that.

What steps will reproduce the problem?
1. Load gsession module
2. Don't touch any configuration
3. Watch your session not working

What is the expected output? What do you see instead?

If you leave the default configuration of gsession, the cookie expiration time 
is now set in the past.

[deleted issue]

What steps will reproduce the problem?
1. Go in the server root.

2. Try to start Caudium with the following line:
----8<----8<----8<----8<----
./start-caudium -M /my/path/module --once
---->8---->8---->8---->8----
it invoques the following and works:
----8<----8<----8<----8<----
/sw/bin/pike7.6 -DENABLE_THREADS -DCAUDIUM -DCAUDIUM_CACHE -DROXEN
-DUSE_SHUFFLER -Ietc/include -Ibase_server -Metc/modules -Mlib/7.6.112/
-w -M /my/path/module -P/sw/lib/caudium1.4
base_server/caudiumloader.pike -M /my/path/module
---->8---->8---->8---->8----


3. Now try to start Caudium with the following line (notice the space change):
----8<----8<----8<----8<----
./start-caudium -M/my/path/module --once
---->8---->8---->8---->8----
it invoques the following and doesn't work:
----8<----8<----8<----8<----
/sw/bin/pike7.6 -DENABLE_THREADS -DCAUDIUM -DCAUDIUM_CACHE -DROXEN
-DUSE_SHUFFLER -Ietc/include -Ibase_server -Metc/modules -Mlib/7.6.112/
-th/module -w -M/my/pa -P/sw/lib/caudium1.4
base_server/caudiumloader.pike -M/my/pa
---->8---->8---->8---->8----

What steps will reproduce the problem?
1. go in Virtual Host Matcher: Regular expression rewrite rules
2. read the sample examples lines
3. expect sales\.theweb\.com to match sales.theweb.com and NOT saleszthewebzcom

What is the expected output? What do you see instead?

> Regexp("sales\.theweb\.com")->match("saleszthewebzcom");  
(1) Result: 1
> Regexp("sales\\.theweb\\.com")->match("saleszthewebzcom");
(2) Result: 0

What steps will reproduce the problem?
1. load the gtext module, set it up to parse documents for colors, but leave 
the list of tags to parse 
empty.
2. load a javascript page containing such kind of code: ( var i = rangeA ; i< 
rangeA+3 ; i++ )
3. your document if mess up

What is the expected output? What do you see instead?

Try <list-tags>, you will see gtext parses for <> and </>

Fix found by Bill during the Berlin or Bust Pike meet up. To be finalized and 
commited into 1.4 and 
1.5

What steps will reproduce the problem?

1. set a cookie using the following code in a page called set_cookie.html:
<set_cookie name="foo" value="bar">

2. access set_cookie.html and check the cookie is set in the browser

3. remove the cookie from the browser

3. now, create a new page set_cookie_include.html with the following code:
<insert file="set_cookie.html">

4. Access set_cookie_include.html. The cookie is not set.


This should be because insert deals with a fake RequestID object and the cookie 
is not set in the 
real RequestID object.
I guess <insert> should have a bunch of side effects like this (feeding 
id->misc and such).