cherrypy-users — For questions about using CherryPy

Re: [Cherrypy-users] Re: Wrong mime-type for CSS

[<Joh...@pe...>]

Thanks Remi,

That makes sense because on my local machine I'm using python 2.3

I didn't think it was relevant, so I didn't mention it before.

I thought I'd actually discovered the reason why www.*cherrypy.org
doesn't use a CSS based layout, yet  ;-D

BTW, apart from all the other advantages of CSS, in a cherrypy
context, it's much simpler to change the appearance of a website
by uploading a small (~4K) css file than to edit/recompile a
large cpy file - and the server doesn't need to be stopped.

John.


                                                                           
             "Remi Delon"                                                  
             <remi@cherrypy.or                                             
             g>                                                         To 
             Sent by:                  <Che...@li...urceforge.n 
             cherrypy-users-ad         et>                                 
             mi...@li...urcef                                          cc 
             orge.net                                                      
                                                                   Subject 
                                       Re: [Cherrypy-users] Re: Wrong      
             28/09/2004 08:09          mime-type for CSS                   
             AM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi John,

> Actually, Remi, I notice that if I use Firefox to view a
> local copy of my web page -- generated on localhost:8080
> by cherrypy-0.10 -- the CSS is recognised.
>
> Has cherrypy been 'fixed', but the version running on
> freecherrypy is a little older?

Actually, this is a Python issue ...
Your FreeCherryPy site was still running with Python-2.1, which didn't have
".css" in "mimetypes.types_map".

I upgraded it to python-2.2 and now your stylesheet works fine.

Regards,

Remi.

PS: Nice to hear from you :-)



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Cherrypy-users mailing list
Che...@li...
https://lists.sourceforge.net/lists/listinfo/cherrypy-users



=============================================================================
CAUTION: This message may contain both confidential and privileged information intended 
only for the addressee named above.  If you are not the intended recipient any dissemination, 
distribution or reproduction of this message is prohibited.  If you have received this message in 
error please notify the sender immediately, then destroy the original message.  Any views
expressed in this message are solely those of the individual sender, except where the sender 
specifically states them to be the views of Peregrine Semiconductor Australia.  All care has been 
taken to screen this message and attachments for computer viruses, however, we accept no 
responsibility for viruses it may contain.

Peregrine Semiconductor Australia Pty Ltd
8 Herb Elliott Ave.,
Homebush Bay 2127.  NSW  Australia.
Ph. +612 9763 4111   Fax. +612 9746 1501
=============================================================================

Re: [Cherrypy-users] Re: Wrong mime-type for CSS

[Remi D. <re...@ch...>]

Hi John,

> Actually, Remi, I notice that if I use Firefox to view a
> local copy of my web page -- generated on localhost:8080
> by cherrypy-0.10 -- the CSS is recognised.
> 
> Has cherrypy been 'fixed', but the version running on
> freecherrypy is a little older?

Actually, this is a Python issue ...
Your FreeCherryPy site was still running with Python-2.1, which didn't have ".css" in "mimetypes.types_map".

I upgraded it to python-2.2 and now your stylesheet works fine.

Regards,

Remi.

PS: Nice to hear from you :-)

[Cherrypy-users] Re: Wrong mime-type for CSS

[<Joh...@pe...>]

Actually, Remi, I notice that if I use Firefox to view a
local copy of my web page -- generated on localhost:8080
by cherrypy-0.10 -- the CSS is recognised.

Has cherrypy been 'fixed', but the version running on
freecherrypy is a little older?

And, of course, I could use an internal style sheet, as
you do on www.cherrypy.org.

Regards,
John.

=============================================================================
CAUTION: This message may contain both confidential and privileged information intended 
only for the addressee named above.  If you are not the intended recipient any dissemination, 
distribution or reproduction of this message is prohibited.  If you have received this message in 
error please notify the sender immediately, then destroy the original message.  Any views
expressed in this message are solely those of the individual sender, except where the sender 
specifically states them to be the views of Peregrine Semiconductor Australia.  All care has been 
taken to screen this message and attachments for computer viruses, however, we accept no 
responsibility for viruses it may contain.

Peregrine Semiconductor Australia Pty Ltd
8 Herb Elliott Ave.,
Homebush 2140.  NSW  Australia.
Ph. +612 9763 4111   Fax. +612 9746 1501
=============================================================================

[Cherrypy-users] Wrong mime-type for CSS

[<Joh...@pe...>]

I've been trying to convert

http://www.freecherrypy.org/johnc

from a table based layout to a CSS layout, in line with 'Web
Standards' principles.

Both the HTML and CSS validate. It displays fine in IE6, but
FireFox ignores the CSS in an external stylesheet, because
Cherrypy's httpd server sends the mime-type as text/plain,
rather than text/css.

IE6 only works because it tends to ignore mime-types, which
is of course undesirable.

Can you put this on your 'to do' list?

Regards,
John Cherry.

=============================================================================
CAUTION: This message may contain both confidential and privileged information intended 
only for the addressee named above.  If you are not the intended recipient any dissemination, 
distribution or reproduction of this message is prohibited.  If you have received this message in 
error please notify the sender immediately, then destroy the original message.  Any views
expressed in this message are solely those of the individual sender, except where the sender 
specifically states them to be the views of Peregrine Semiconductor Australia.  All care has been 
taken to screen this message and attachments for computer viruses, however, we accept no 
responsibility for viruses it may contain.

Peregrine Semiconductor Australia Pty Ltd
8 Herb Elliott Ave.,
Homebush 2140.  NSW  Australia.
Ph. +612 9763 4111   Fax. +612 9746 1501
=============================================================================

Re: [Cherrypy-users] How to use cgitb and CherryPy?

[Remi D. <re...@ch...>]

----- Original Message ----- 
From: "Remi Delon" <re...@ch...>
To: <Che...@li...>
Sent: Wednesday, September 22, 2004 11:38 PM
Subject: Re: [Cherrypy-users] How to use cgitb and CherryPy?


> 
>> Can cgitb be used to make nice looking error pages with CherryPy?  It is very nice for debugging because it shows the variable 
>> contents as well as the traceback.
> 
> Well, if it is based on the environment variables that are usually passed to cgi scripts, then it probably won't work.
> But you could easily override "onError" to display the variables on your own ...
> 
> Remi.
>

[Cherrypy-users] How to use cgitb and CherryPy?

[Scott C. <sco...@mi...>]

Can cgitb be used to make nice looking error pages with CherryPy?  It is very nice for debugging because it shows the variable contents as well as the traceback.

Scott

Re: [Cherrypy-users] Re: What's new ?

[Remi D. <re...@ch...>]

>> Other than that, the only place where CherryPy could do some unicode stuff is when it receives parameters sent by the browser. 
>> The
>> browser always sends form values in an encoded format (you can specify which encoding you want), and CherryPy could automatically
>> decode them into unicode.
>> But I don't think CherryPy should do that because we might not want to decode *all* parameters or *always* use the same encoding, 
>> so
>> I think it's up to the application developers to decode the parameters themselves.
>
> I think that makes sense to have settings to enable/disable automatic
> encoding of parameters. It's a nice feature to have parameters always in
> the same encoding withouth concern of client browser settings, freeing
> the programmer of the repetitive task of reencode/check the data
> received.
> More info on browser misbehave:
> http://ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html
> A problem arise. What happens if the programmer specified iso-8859 to
> cherrypy input and the form encoding of the form submit is UTF-8 and has
> some japaneese characters? All UTF-8 cannot be contained in iso-8859,
> exception raises. A handler (onEncodingError?) for this situation could
> be added to display a programmer specified error (or cherrypy default if
> not).
> Anoter nice addition could be to have a 'request.encoding' to free the
> programmer from using the headerMap to extract these. Also add
> 'request.content-type'?

Sorry about the delay ...
I don't see any reason not to do what you suggest (people don't have to use these features if they don't want to). But this will be 
lower priority and probably won't make it in the first releases ...

Remi.

Re: [Cherrypy-users] Re: What's new ?

[Eduardo R. <tr...@mu...>]

On Thu, 2004-09-09 at 10:01, Remi Delon wrote:

> Other than that, the only place where CherryPy could do some unicode stuff is when it receives parameters sent by the browser. The 
> browser always sends form values in an encoded format (you can specify which encoding you want), and CherryPy could automatically 
> decode them into unicode.
> But I don't think CherryPy should do that because we might not want to decode *all* parameters or *always* use the same encoding, so 
> I think it's up to the application developers to decode the parameters themselves.

I think that makes sense to have settings to enable/disable automatic
encoding of parameters. It's a nice feature to have parameters always in
the same encoding withouth concern of client browser settings, freeing
the programmer of the repetitive task of reencode/check the data
received.
More info on browser misbehave:
http://ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html
A problem arise. What happens if the programmer specified iso-8859 to
cherrypy input and the form encoding of the form submit is UTF-8 and has
some japaneese characters? All UTF-8 cannot be contained in iso-8859,
exception raises. A handler (onEncodingError?) for this situation could
be added to display a programmer specified error (or cherrypy default if
not).
Anoter nice addition could be to have a 'request.encoding' to free the
programmer from using the headerMap to extract these. Also add
'request.content-type'?

Re: [Cherrypy-users] Re: What's new ?

[Remi D. <re...@ch...>]

> What are the plans for :
>
> - Unicode

Well, the new version of CherryTemplate supports unicode, so all processing of the template and variables now happen in unicode. You 
can also tell it to encode the resulting page just before returning it, and you can specify the encoding. The default is to encode 
everything to ascii at the end.

Other than that, the only place where CherryPy could do some unicode stuff is when it receives parameters sent by the browser. The 
browser always sends form values in an encoded format (you can specify which encoding you want), and CherryPy could automatically 
decode them into unicode.
But I don't think CherryPy should do that because we might not want to decode *all* parameters or *always* use the same encoding, so 
I think it's up to the application developers to decode the parameters themselves.


> - HTTP 1.1

Well, this one is still in the TODO list (but it doesn't have a very high priority at the moment ...)

Remi.

[Cherrypy-users] Re: What's new ?

[Sylvain H. <sh...@de...>]

Sounds great :)

What are the plans for :

- Unicode
- HTTP 1.1

Sylvain

Remi Delon wrote:
>> What is new around here ?
>>
>> Rémi, did you get the chance to work on CP2 ?
> 
> 
> Yes, I did make some progress on CP2 ...
> First of all, we now have a new repository for the CP2 code.
> I got frustrated with the SourceForge CVS tree and Hendrik generously 
> set up a Subversion tree.
> If you have a Subversion client such as TortoiseSvn, you can check out 
> the tree from: http://svn.mans.de/cherrypy/cp2/.
> 
> The tree comes with a file test.py that demonstrates a few of the new 
> CP2 features/syntax:
> 
> # Sample site to demonstrate how CP2 and CherryTemplate work
> 
> from CherryPy import cpServer, cpg
> from CherryPy.Lib.CSAuthenticate import CSAuthenticate
> from CherryTemplate.CherryTemplate import renderTemplate
> 
> class Root:
>    def _cpInitRequest(self):
>        # Sample initRequest to demonstrate how to redirect "index3" to 
> "index"
>        if cpg.request.path == 'index3':
>            cpg.request.path = 'index'
> 
>    def _cpInitThread(self, num):
>        print "init thread:", num
> 
>    def index(self):
>        return "<html><body>Hello, world</body></html>"
>    index.exposed = True
>    def index2(self, name="world"):
>        return renderTemplate(locals(), globals(), """
>            <html><body>
>                Hello, <py-eval="name">
>            </body></html>
>        """)
>    index2.exposed = True
>    def privateMethod(self):
>        pass
> 
> cpg.root = Root()
> 
> class A:
>    def _cpInitRequest(self):
>        # Sample initRequest to demonstrate how to redirect "index3" to "b"
>        if cpg.request.path == 'a/index3':
>            cpg.request.path = 'a/b'
>    def b(self):
>        return "a.b"
>    b.exposed = True
>    def default(self):
>        return "a.default"
>    default.exposed = True
> 
> cpg.root.a = A()
> 
> class Protected(CSAuthenticate):
>    def index(self):
>        return renderTemplate(locals(), globals(), """
>            If you see this, you are logged in as, 
> <py-eval="cpg.request.login">
>        """)
>    index.exposed = True
> 
> cpg.root.protected = Protected()
> 
> cpServer.start(configFile = 'test.cpg')
> 
> 
> The most noticable changes are:
> - you now have to explicitely say "method.exposed = True" to expose a 
> method. This is for security reasons and using this syntax works well 
> with inheritance ...
> - instead of using the ugly "class A_b" for the path /a/b, you now 
> write: cpg.root.a.b = B()
> - special functions like "initRequest" have been renamed 
> "_cpInitRequest" and are now methods within the classes, which means 
> that you can have different such methods for different parts of your site.
> 
> I think that the core of CP2 is now working well and I (and hopefully 
> Hendrik as well ;-)) are going to work on "side" things such as 
> rewriting the regression test suite, adding back XML-RPC and SSL 
> support, ...
> When this is done, we'll release a cherrypy-2.0-alpha release.
> 
> Remi.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idP47&alloc_id808&op=click
> 

Re: [Cherrypy-users] What's new ?

[Remi D. <re...@ch...>]

> What is new around here ?
>
> R=E9mi, did you get the chance to work on CP2 ?

Yes, I did make some progress on CP2 ...
First of all, we now have a new repository for the CP2 code.
I got frustrated with the SourceForge CVS tree and Hendrik generously set=
 up a Subversion tree.
If you have a Subversion client such as TortoiseSvn, you can check out th=
e tree from: http://svn.mans.de/cherrypy/cp2/.

The tree comes with a file test.py that demonstrates a few of the new CP2=
 features/syntax:

# Sample site to demonstrate how CP2 and CherryTemplate work

from CherryPy import cpServer, cpg
from CherryPy.Lib.CSAuthenticate import CSAuthenticate
from CherryTemplate.CherryTemplate import renderTemplate

class Root:
    def _cpInitRequest(self):
        # Sample initRequest to demonstrate how to redirect "index3" to "=
index"
        if cpg.request.path =3D=3D 'index3':
            cpg.request.path =3D 'index'

    def _cpInitThread(self, num):
        print "init thread:", num

    def index(self):
        return "<html><body>Hello, world</body></html>"
    index.exposed =3D True
    def index2(self, name=3D"world"):
        return renderTemplate(locals(), globals(), """
            <html><body>
                Hello, <py-eval=3D"name">
            </body></html>
        """)
    index2.exposed =3D True
    def privateMethod(self):
        pass

cpg.root =3D Root()

class A:
    def _cpInitRequest(self):
        # Sample initRequest to demonstrate how to redirect "index3" to "=
b"
        if cpg.request.path =3D=3D 'a/index3':
            cpg.request.path =3D 'a/b'
    def b(self):
        return "a.b"
    b.exposed =3D True
    def default(self):
        return "a.default"
    default.exposed =3D True

cpg.root.a =3D A()

class Protected(CSAuthenticate):
    def index(self):
        return renderTemplate(locals(), globals(), """
            If you see this, you are logged in as, <py-eval=3D"cpg.reques=
t.login">
        """)
    index.exposed =3D True

cpg.root.protected =3D Protected()

cpServer.start(configFile =3D 'test.cpg')


The most noticable changes are:
 - you now have to explicitely say "method.exposed =3D True" to expose a =
method. This is for security reasons and using this syntax=20
works well with inheritance ...
 - instead of using the ugly "class A_b" for the path /a/b, you now write=
: cpg.root.a.b =3D B()
 - special functions like "initRequest" have been renamed "_cpInitRequest=
" and are now methods within the classes, which means that=20
you can have different such methods for different parts of your site.

I think that the core of CP2 is now working well and I (and hopefully Hen=
drik as well ;-)) are going to work on "side" things such=20
as rewriting the regression test suite, adding back XML-RPC and SSL suppo=
rt, ...
When this is done, we'll release a cherrypy-2.0-alpha release.

Remi.

[Cherrypy-users] What's new ?

[Sylvain H. <sh...@de...>]

Hey guys,

What is new around here ?

Rémi, did you get the chance to work on CP2 ?

- Sylvain

[Cherrypy-users] Re: [ANN] First CP2 code in the CVS tree

[Sylvain H. <sh...@de...>]

Good job Remi.

I'll play with it and let you know asap.

- Sylvain


Remi Delon wrote:
> Hello everyone,
> 
> I've just added to the CVS tree some initial code for "CherryPy-2".
> Everything is in a directory called "CP2". There is a file called Test/test.py that demonstrates how CP2 works.
> This code is still "very" beta and is full of "TBCs" everywhere :-) but it is already quite usable.
> The "Lib/" dir only has 2 modules so far: "Aspect.py", which provides a class for implementing some "aspect" features and
> "CSAuthenticate.py", which uses "Aspect.py".
> 
> The templating language has been renamed "CherryTemplate" and now comes as a separate/standalone package (it is in the same CVS tree
> though).
> 
> Feel free to play with it and give me some feedback.
> 
> Remi.
> 
> 
> PS: In case you haven't been following: CherryPy-2 is an (almost) full rewrite of CherryPy. The main change is that the compilation
> phase has disappeared and people now write pure python code to develop their site (no more "CherryClasses" ...). Also, the license
> has changed from GPL to BSD.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

[Cherrypy-users] [ANN] First CP2 code in the CVS tree

[Remi D. <re...@ch...>]

Hello everyone,

I've just added to the CVS tree some initial code for "CherryPy-2".
Everything is in a directory called "CP2". There is a file called Test/test.py that demonstrates how CP2 works.
This code is still "very" beta and is full of "TBCs" everywhere :-) but it is already quite usable.
The "Lib/" dir only has 2 modules so far: "Aspect.py", which provides a class for implementing some "aspect" features and
"CSAuthenticate.py", which uses "Aspect.py".

The templating language has been renamed "CherryTemplate" and now comes as a separate/standalone package (it is in the same CVS tree
though).

Feel free to play with it and give me some feedback.

Remi.


PS: In case you haven't been following: CherryPy-2 is an (almost) full rewrite of CherryPy. The main change is that the compilation
phase has disappeared and people now write pure python code to develop their site (no more "CherryClasses" ...). Also, the license
has changed from GPL to BSD.

[Cherrypy-users] Re: CP2: License change ?

[Sylvain H. <sh...@de...>]

I wouldn't mind either.

- Sylvain

Alan Green wrote:
> BSD would be great. I'd also be happy with LGPL.
> 
> Alan.
> 
> ----- Original Message ----- 
> From: "Chris Foote" <ch...@in...>
> To: "Remi Delon" <re...@ch...>
> Cc: <che...@li...>
> Sent: Wednesday, July 14, 2004 9:56 AM
> Subject: Re: [Cherrypy-users] CP2: License change ?
> 
> 
> 
>>On Tue, 13 Jul 2004, Remi Delon wrote:
>>
>>
>>>CP2 will be very different to CP1 with respect to how it interacts with
> 
> people's source code.
> 
>>>While CP1 was very much like a "compiler", CP2 will be a "python module"
> 
> ...
> 
>>>Since I want as many people as possible to use CherryPy (in both open
> 
> and closed source software) I'm thinking of changing the
> 
>>>license from GPL to BSD ...
>>>
>>>What do people think ?
>>
>>Excellent idea!
>>
>>Chris Foote <ch...@in...>
>>   _                  _         _    Jabber: ch...@ja...
>>  (_)                | |       | |   Director - INETD PTY LTD
>>   _   _ __     ___  | |_    __| |   Level 2, 132 Franklin St
>>  | | | '_ \   / _ \ | __|  / _` |   Adelaide SA 5000
>>  | | | | | | |  __/ | |_  | (_| |   Web:   http://www.inetd.com.au
>>  |_| |_| |_|  \___|  \__|  \__,_|   Phone: (08) 8410 4566
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by Black Hat Briefings & Training.
>>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>>digital self defense, top technical experts, no vendor pitches,
>>unmatched networking opportunities. Visit www.blackhat.com
>>_______________________________________________
>>Cherrypy-users mailing list
>>Che...@li...
>>https://lists.sourceforge.net/lists/listinfo/cherrypy-users
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com

Re: [Cherrypy-users] CP2: License change ?

[Alan G. <ag...@ci...>]

BSD would be great. I'd also be happy with LGPL.

Alan.

----- Original Message ----- 
From: "Chris Foote" <ch...@in...>
To: "Remi Delon" <re...@ch...>
Cc: <che...@li...>
Sent: Wednesday, July 14, 2004 9:56 AM
Subject: Re: [Cherrypy-users] CP2: License change ?


> On Tue, 13 Jul 2004, Remi Delon wrote:
>
> > CP2 will be very different to CP1 with respect to how it interacts with
people's source code.
> > While CP1 was very much like a "compiler", CP2 will be a "python module"
...
> >
> > Since I want as many people as possible to use CherryPy (in both open
and closed source software) I'm thinking of changing the
> > license from GPL to BSD ...
> >
> > What do people think ?
>
> Excellent idea!
>
> Chris Foote <ch...@in...>
>    _                  _         _    Jabber: ch...@ja...
>   (_)                | |       | |   Director - INETD PTY LTD
>    _   _ __     ___  | |_    __| |   Level 2, 132 Franklin St
>   | | | '_ \   / _ \ | __|  / _` |   Adelaide SA 5000
>   | | | | | | |  __/ | |_  | (_| |   Web:   http://www.inetd.com.au
>   |_| |_| |_|  \___|  \__|  \__,_|   Phone: (08) 8410 4566
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Cherrypy-users mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/cherrypy-users
>

Re: [Cherrypy-users] CP2: License change ?

[Chris F. <ch...@in...>]

On Tue, 13 Jul 2004, Remi Delon wrote:

> CP2 will be very different to CP1 with respect to how it interacts with people's source code.
> While CP1 was very much like a "compiler", CP2 will be a "python module" ...
>
> Since I want as many people as possible to use CherryPy (in both open and closed source software) I'm thinking of changing the
> license from GPL to BSD ...
>
> What do people think ?

Excellent idea!

Chris Foote <ch...@in...>
   _                  _         _    Jabber: ch...@ja...
  (_)                | |       | |   Director - INETD PTY LTD
   _   _ __     ___  | |_    __| |   Level 2, 132 Franklin St
  | | | '_ \   / _ \ | __|  / _` |   Adelaide SA 5000
  | | | | | | |  __/ | |_  | (_| |   Web:   http://www.inetd.com.au
  |_| |_| |_|  \___|  \__|  \__,_|   Phone: (08) 8410 4566

[Cherrypy-users] CP2: License change ?

[Remi D. <re...@ch...>]

Here we go again :-)

CP2 will be very different to CP1 with respect to how it interacts with people's source code.
While CP1 was very much like a "compiler", CP2 will be a "python module" ...

Since I want as many people as possible to use CherryPy (in both open and closed source software) I'm thinking of changing the
license from GPL to BSD ...

What do people think ?

Remi.

Re: [Cherrypy-users] cherrypy + apache + pcgi - status ????

[Remi D. <re...@ch...>]

Alex,

> Greetings!!
>  I realized on cherrypy feedback of files in parts (206 code).
>  If as a web-server I use built - in in cherrypy - all perfectly. If with the
> help pcgi apache - that the code is not transferred the client.
>  I think that somehow it is necessary to correct cherrypcgi.cgi, but I do not
> know as - prompt please.
>
> ------ httpd.conf apache -------------
> RewriteEngine On
> RewriteCond  %{HTTP:Authorization}  ^(.*)
> RewriteRule ^(.*) /fs/http/murphy/dnroot/cherrypcgi.cgi$1
> [e=HTTP_CGI_AUTHORIZATION:%1,t=application/x-httpd-cgi,l]
> ---------------------------------------
> ----- Me CPY ---------------------
> response.headerMap['status'] = '206 Partial Content'
> response.headerMap['protocolVersion'] = 'HTTP/1.1'
> response.wfile.write('HTTP/1.1 206 Partial Content\r\n')
> response.wfile.write('Content-Type: application/octet-stream\r\n')
> response.wfile.write('Accept-Ranges: bytes\r\n')
> response.wfile.write('Proxy-connection: close\r\n')

You should only use "response.wfile.write" if you want to stream back the response to the browser as opposed to letting CherryPy
handle it for you.
If you do use response.wfile.write, then you don't need to set values in headerMap because they won't get used ... And you also have
to set "response.sendResponse = 0"


> ....
> ---------------------
> ---- wget from cherrypy server -----------
> bash-2.05b$ wget -S -c http://192.168.1.4/?id=115
>            => `index.html?id=115'
>  1 HTTP/1.1 206 Partial Content
>  2 Content-Type: application/octet-stream
>  3 Content-Disposition: inline; filename="winex3_3.3-1.i386.tgz"
>  4 Accept-Ranges: bytes
>  7 Cache-Control: None
>  8 server: CherryPy/0.10
>  9 Pragma: no-cache
> 10 Content-Range: bytes 799826-7206567/7206568
> 11 Content-Length: 6406742
> 12 Proxy-connection: close
> -----------------------------------------
> ------ wget from apache pcgi ------------
> bash-2.05b$ wget -S -c http://192.168.1.4/?id=115
>            => `index.html?id=115'
>  1 HTTP/1.1 200 OK
>  2 Content-Type: application/octet-stream
>  3 Content-Disposition: inline; filename="winex3_3.3-1.i386.tgz"
>  4 Server: Apache/2.0.49 (Gentoo/Linux)Server: Apache/2.0.49 (Gentoo/Linux)
>  5 Accept-Ranges: bytes
>  6 Cache-Control: None
>  7 Pragma: no-cache
>  8 Content-Range: bytes 799826-7206567/7206568
>  9 Content-Length: 6406742
> 10 Proxy-connection: close
> ------------------------------------------
>
> Apparently above the apache does not react on transferred to it a code 206 and
> persistently gives out 200 - what to do????

Well, I just looked at the source code for cherrypypcgi.cgi and it does transfer the status to Apache, but not the reason string
("Partial Content"). I wonder if that may be the reason why Apache is not returning 206 ...
I know that in some cases Apache thinks it knows better than you what to send to the browser and it actually changes the headers
that you're sending ...
You could try debugging the cherrypypcgi.cgi (one way to do this is to save in a file the values it's sending to Apache) and see if
Apache is changing them or not ...

Remi.

[Cherrypy-users] cherrypy + apache + pcgi - status ????

[Alex M. <mu...@sg...>]

Greetings!!
 I realized on cherrypy feedback of files in parts (206 code).
 If as a web-server I use built - in in cherrypy - all perfectly. If with the 
help pcgi apache - that the code is not transferred the client.
 I think that somehow it is necessary to correct cherrypcgi.cgi, but I do not 
know as - prompt please. 

------ httpd.conf apache -------------
RewriteEngine On
RewriteCond  %{HTTP:Authorization}  ^(.*)
RewriteRule ^(.*) /fs/http/murphy/dnroot/cherrypcgi.cgi$1 
[e=HTTP_CGI_AUTHORIZATION:%1,t=application/x-httpd-cgi,l]
---------------------------------------
----- Me CPY ---------------------
response.headerMap['status'] = '206 Partial Content'
response.headerMap['protocolVersion'] = 'HTTP/1.1'
response.wfile.write('HTTP/1.1 206 Partial Content\r\n')
response.wfile.write('Content-Type: application/octet-stream\r\n')
response.wfile.write('Accept-Ranges: bytes\r\n')
response.wfile.write('Proxy-connection: close\r\n')
....
---------------------
---- wget from cherrypy server -----------
bash-2.05b$ wget -S -c http://192.168.1.4/?id=115
           => `index.html?id=115'
 1 HTTP/1.1 206 Partial Content
 2 Content-Type: application/octet-stream
 3 Content-Disposition: inline; filename="winex3_3.3-1.i386.tgz"
 4 Accept-Ranges: bytes
 7 Cache-Control: None
 8 server: CherryPy/0.10
 9 Pragma: no-cache
10 Content-Range: bytes 799826-7206567/7206568
11 Content-Length: 6406742
12 Proxy-connection: close
-----------------------------------------
------ wget from apache pcgi ------------
bash-2.05b$ wget -S -c http://192.168.1.4/?id=115
           => `index.html?id=115'
 1 HTTP/1.1 200 OK
 2 Content-Type: application/octet-stream
 3 Content-Disposition: inline; filename="winex3_3.3-1.i386.tgz"
 4 Server: Apache/2.0.49 (Gentoo/Linux)Server: Apache/2.0.49 (Gentoo/Linux)
 5 Accept-Ranges: bytes
 6 Cache-Control: None
 7 Pragma: no-cache
 8 Content-Range: bytes 799826-7206567/7206568
 9 Content-Length: 6406742
10 Proxy-connection: close
------------------------------------------

Apparently above the apache does not react on transferred to it a code 206 and 
persistently gives out 200 - what to do???? 
						

[Cherrypy-users] Re: Inheritance or global module

[Sylvain H. <sh...@de...>]

I folow you Remi.

The first approch has some neat features like the automagically 
registering but as you stated it is also weird that we share 
self.request across modules when they don't share anything in fact.



Remi Delon wrote:
> Well, to summarize the 2 main options we have for passing around global data, we have:
> 
> 1- The "inheritance" way:
>     - Classes declared by users have to derive from a common class (for instance "CherryClass") in order to be exposed.
>     - Request and response are accessed through "self.request" and "self.response".
>     - "Exposed class instances" are registered automagically when the instance is created.
>     - So, the code looks basically like this:
> 
> from CherryPy import CherryClass
> 
> class Root(CherryClass):
>     def index(self):
>         if self.request ....
>         return "<html><body>OK</body></html>"
> 
> root = Root() # This automagically registers "root" as being exposed
> 
> 2- The "global module" way:
>     - All modules have to import a global CherryPy module (for instance "cpg", for "CherryPyGlobals)
>     - Request and response are accessed through cpg.request and cpg.response
>     - "Exposed class instances" are registered by sticking them into cpg (or we could make user explicitely call "cpg.register()" )
>     - So, the code looks basically like this:
> 
> from CherryPy import cpg
> 
> class Root:
>     def index(self):
>         if cpg.request ....
>         return "<html><body>OK</body></html>"
> 
> cpg.root = Root()  # or cpg.register(root)
> 
> 
> Before we move on, we need to decide which option we want to choose.
> I tend to slightly prefer the 2nd option, because:
>     - You don't have to derive all your classes from CherryClass
>     - In option 1, it seems a bit weird that self.request is always the same thing accross different classes/modules (in other
> words, we use "self.request" but "request" has nothing to do with the current instance)
>     - With option 2, you can create multiple instances and give them different names. For instance, you could have this:
>     cpg.root = Root() # Would provide http://domain.com
>     cpg.other = Root() # Would provide http://domain.com/other
>     ...
> 
> 
> What do you think ?
> 
> 
> Remi.
> 
> 
> PS: I'm cross-posting this to cherrypy-devel, so let's now only respond to cherrypy-devel ...
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com

[Cherrypy-users] Inheritance or global module

[Remi D. <re...@ch...>]

Well, to summarize the 2 main options we have for passing around global data, we have:

1- The "inheritance" way:
    - Classes declared by users have to derive from a common class (for instance "CherryClass") in order to be exposed.
    - Request and response are accessed through "self.request" and "self.response".
    - "Exposed class instances" are registered automagically when the instance is created.
    - So, the code looks basically like this:

from CherryPy import CherryClass

class Root(CherryClass):
    def index(self):
        if self.request ....
        return "<html><body>OK</body></html>"

root = Root() # This automagically registers "root" as being exposed

2- The "global module" way:
    - All modules have to import a global CherryPy module (for instance "cpg", for "CherryPyGlobals)
    - Request and response are accessed through cpg.request and cpg.response
    - "Exposed class instances" are registered by sticking them into cpg (or we could make user explicitely call "cpg.register()" )
    - So, the code looks basically like this:

from CherryPy import cpg

class Root:
    def index(self):
        if cpg.request ....
        return "<html><body>OK</body></html>"

cpg.root = Root()  # or cpg.register(root)


Before we move on, we need to decide which option we want to choose.
I tend to slightly prefer the 2nd option, because:
    - You don't have to derive all your classes from CherryClass
    - In option 1, it seems a bit weird that self.request is always the same thing accross different classes/modules (in other
words, we use "self.request" but "request" has nothing to do with the current instance)
    - With option 2, you can create multiple instances and give them different names. For instance, you could have this:
    cpg.root = Root() # Would provide http://domain.com
    cpg.other = Root() # Would provide http://domain.com/other
    ...


What do you think ?


Remi.


PS: I'm cross-posting this to cherrypy-devel, so let's now only respond to cherrypy-devel ...

Re: [Cherrypy-users] [CP2] Compatibility

[Remi D. <re...@ch...>]

> I was thinking of the compatibility of the next CP version and I do not 
> think we should keep backward compatibility.
> 
> My reasons for that :
> 
> 1 - It will involve more work
> 2 - It will increase the number of potential bugs
> 3 - Above all, IMO it will screw the design of the new CP. If we need to 
> keep compatibility we will need to tweak our ideas to do so and I don't 
> see the point.
> 
> I think many people need and want to keep backward compatibility but IMO 
> it is the right time to break it as even though many of us have 
> application that run fine with the current CP.
> 
> IMO, the current CP is working alright on its own enough to use it. If 
> Remi decides to make a new version of CP, I think it shoud be better to 
> start from scratch and simply take the best of CP1.


I totaly agree :-)
I also think it should be possible to provide a script that migrates .cpy files to CP2 .py files (at least in most cases).

Remi.

Re: [Cherrypy-users] Re: New CherryPy: Passing around global variables ?

[Chema <py...@ch...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 24 June 2004 16:40, Remi Delon wrote:

> So which special method would you override in the Metaclass to keep track
> of the derived classes. Would that work accross different modules ?

The implementation would by something like this:

#----(CherryPy Module)-------
import weakref

class metaCherryClass(type):

  def __init__(cls,name,bases,dic):
    cls.__cherry_pool__[name]=3Dcls


class CherryClass(object):
  __metaclass__=3DmetaCherryClass
  __cherry_pool__=3Dweakref.WeakValueDictionary()

  def __new__(cls):
    it=3Dcls.__dict__.get("__it__")
    if not it:
      cls.__it__=3Dit=3Dobject.__new__(cls)
    return it

#----(end module)----

#---- (user's application)----
from CherryPy import CherryClass

class Root(CherryClass):pass

class MyRoot(Root):pass

print CherryClass.__cherry_pool__.keys()
#Results: ['Root', 'MyRoot', 'CherryClass']
#-------------------------


I have included the singleton pattern into CherryClass (only one instance f=
or=20
class):

class Root(CherryClass):pass

root=3DRoot()
root2=3DRoot()
assert root2 is root

It would be possible to initialize automatically the singleton instance,=20
leaving this as optional task for the final user.=20

And yes, it works accross different modules. Perhaps, we must continue this=
=20
discussion in the developer's list.

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFA4AAPHLTQrABk8H0RAvglAKD98tRhzl2JTvZRxB5c+IXWQh+UxACg0Sp9
Yg0FR0Yqoum6aI6uI36G6qM=3D
=3D7+7L
=2D----END PGP SIGNATURE-----

[Cherrypy-users] [CP2] Compatibility

[Sylvain H. <sh...@de...>]

Hi guys,

I was thinking of the compatibility of the next CP version and I do not 
think we should keep backward compatibility.

My reasons for that :

1 - It will involve more work
2 - It will increase the number of potential bugs
3 - Above all, IMO it will screw the design of the new CP. If we need to 
keep compatibility we will need to tweak our ideas to do so and I don't 
see the point.

I think many people need and want to keep backward compatibility but IMO 
it is the right time to break it as even though many of us have 
application that run fine with the current CP.

IMO, the current CP is working alright on its own enough to use it. If 
Remi decides to make a new version of CP, I think it shoud be better to 
start from scratch and simply take the best of CP1.

Please don't shoot me :)

Bye,
- Sylvain