headers
Stefan de Konink | 1 Jun 2008 13:45
Picon
Picon
Favicon

HTTP_PUT / HTTP_POST in a handler

Hi,

How can I process a http_put/post request (the payload) in a handler. Or
better: where can I access it?

Stefan
Permalink | Reply | 4 comments |
headers
Alvaro Lopez Ortega | 1 Jun 2008 14:43
Picon
Gravatar

Re: HTTP_PUT / HTTP_POST in a handler

On 1 Jun 2008, at 13:45, Stefan de Konink wrote:

> How can I process a http_put/post request (the payload) in a  
> handler. Or
> better: where can I access it?

&HANDLER_CONN(handler)->post is the object containing the post  
information. Its interface is defined in cherokee/post.h.

--
Greetings, alo.
http://www.alobbs.com/
Permalink | Reply | 3 comments |
headers
Stefan de Konink | 1 Jun 2008 14:45
Picon
Picon
Favicon

Re: HTTP_PUT / HTTP_POST in a handler

Alvaro Lopez Ortega schreef:
> On 1 Jun 2008, at 13:45, Stefan de Konink wrote:
> 
>> How can I process a http_put/post request (the payload) in a handler. Or
>> better: where can I access it?
> 
> &HANDLER_CONN(handler)->post is the object containing the post 
> information. Its interface is defined in cherokee/post.h.

So a put request will have its data there too?

Stefan
Permalink | Reply | 2 comments |
headers
Alvaro Lopez Ortega | 1 Jun 2008 15:05
Picon
Gravatar

Re: HTTP_PUT / HTTP_POST in a handler

On 1 Jun 2008, at 14:45, Stefan de Konink wrote:
> Alvaro Lopez Ortega schreef:
>> On 1 Jun 2008, at 13:45, Stefan de Konink wrote:
>>> How can I process a http_put/post request (the payload) in a  
>>> handler. Or
>>> better: where can I access it?
>> &HANDLER_CONN(handler)->post is the object containing the post  
>> information. Its interface is defined in cherokee/post.h.
>
> So a put request will have its data there too?

Even if the server core is ready for the less common HTTP methods,  
none of the handlers that we are currently shipping support methods  
besides GET, POST and HEAD. Actually, I could not assure whether it  
will work.

Give it a try. If for any reason it does not work, let me know and I  
will check it out.

--
Greetings, alo.
http://www.alobbs.com/
Permalink | Reply | 1 comment |
headers
Stefan de Konink | 1 Jun 2008 17:35
Picon
Picon
Favicon

Re: HTTP_PUT / HTTP_POST in a handler

Alvaro Lopez Ortega schreef:
> On 1 Jun 2008, at 14:45, Stefan de Konink wrote:
>> Alvaro Lopez Ortega schreef:
>>> On 1 Jun 2008, at 13:45, Stefan de Konink wrote:
>>>> How can I process a http_put/post request (the payload) in a 
>>>> handler. Or
>>>> better: where can I access it?
>>> &HANDLER_CONN(handler)->post is the object containing the post 
>>> information. Its interface is defined in cherokee/post.h.
>>
>> So a put request will have its data there too?
> 
> 
> Even if the server core is ready for the less common HTTP methods, none 
> of the handlers that we are currently shipping support methods besides 
> GET, POST and HEAD. Actually, I could not assure whether it will work.
> 
> Give it a try. If for any reason it does not work, let me know and I 
> will check it out.

I guess you forgot a type in http_method_with_input ;)

                                    (m == http_put)      || \

Add this to http.h :) I see now the post has a length.

Stefan
Permalink | Reply | 0 comments |
headers
Stefan de Konink | 2 Jun 2008 05:37
Picon
Picon
Favicon

Stoping the handler if connection is dropped

How can one check in the handler if the connection is still active?

Basically; if processing of SQL takes long and someone starts pressing 
F5 you don't want to process everything again n-times total. If only the 
last time goes to the user.

Stefan
Permalink | Reply | 1 comment |
headers
Alvaro Lopez Ortega | 2 Jun 2008 09:53
Picon
Gravatar

Re: Stoping the handler if connection is dropped

On 2 Jun 2008, at 05:37, Stefan de Konink wrote:

> How can one check in the handler if the connection is still active?
>
> Basically; if processing of SQL takes long and someone starts pressing
> F5 you don't want to process everything again n-times total. If only  
> the
> last time goes to the user.

When you force your browser to reload, if closes the connection and  
opens a new one.. which means that cherokee will close the internal  
connection as well. When a server connection is closed, the handler is  
freed.

The best approach for your case would be to set a global "proxy"  
object. This object would handle the connection to your data source,  
and in case your handler requests the same object twice (from  
different client connections), it would just keep one connection open.

By the way, the proxy object must be thread safe. Something like a  
monitor [1] would be fairly easy to implement..

  1.- http://en.wikipedia.org/wiki/Monitor_%28synchronization%29

--
Greetings, alo.
http://www.alobbs.com/
Permalink | Reply | 0 comments |
headers
Alvaro Lopez Ortega | 4 Jun 2008 17:27
Picon
Gravatar

Cherokee 0.7.1 "As seen on TV" released

          ==========================================
           Cherokee 0.7.1 "As seen on TV" released!
          ==========================================

Cherokee is a very fast, flexible and easy to configure Web Server.
It supports the widespread technologies nowadays: FastCGI, SCGI, PHP,
CGI, TLS and SSL encrypted connections, Virtual hosts, Authentication,
on the fly encoding, Apache compatible log files, load balancing,
and much more.

Cherokee also provides an easy to use configuration interface that
allows to configure the server from top to bottom without having to
edit a text configuration file.

Please visit the Cherokee Web Server site for more information:

              http://www.cherokee-project.com/

Availability
------------
- Main site:
http://www.cherokee-project.com/download/0.7/0.7.1/cherokee-0.7.1.tar.gz

Changes
-------
This is a bug fixing release; it does not include any new feature.
This list summarizes the main changes since Cherokee 0.7.0:

- Minor compilation issues have been fixed
- A couple of bugs have been fixed in cherokee-admin
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan de Konink | 5 Jun 2008 16:55
Picon
Picon
Favicon

Handler and Validation

Hi,

I would like to get access of the validation information inside a 
handler. I guess for this to work I should initialize the validator 
functions.

The actual authentication is not (yet) important, I just want to get 
access to the username and provided password.

If this is only possible using a validator, would it be possible to set 
this validation only on a POST/PUT request?

Stefan
Permalink | Reply | 2 comments |
headers
Alvaro Lopez Ortega | 5 Jun 2008 17:19
Picon
Gravatar

Re: Handler and Validation

On 5 Jun 2008, at 16:55, Stefan de Konink wrote:

> I would like to get access of the validation information inside a
> handler. I guess for this to work I should initialize the validator
> functions.
>
> The actual authentication is not (yet) important, I just want to get
> access to the username and provided password.

The authentication information will be in the connection structure:  
cherokee_connection_t. You can access it by using HANDLER_CONN(handler).

> If this is only possible using a validator, would it be possible to  
> set
> this validation only on a POST/PUT request?

I haven't done that before.. I would have to test it out. Anyway, why  
would you do that? Isn't it a little bit weird?

You could perform the validation within the handler, that's for sure.  
Although, I still think that would be -at least- a very unusual thing  
to do.

--
Greetings, alo.
http://www.alobbs.com/
Permalink | Reply | 1 comment |

Gmane