Re: [PHP] Acentos en tpl
2011/3/17 Lorena Monroy O. : > Hola a todos > Tengo un formulario que tiene dos paneles (.tpl), el cual maneja variables > que vienen de php con la funcion setVariable, pero en el panel del menu me > carga las tildes correctamente y a la derecha me las carga como un rombo con > interrogación. Manejo Firefox y probe cambiando la configuración de > caracteres de UTF-8 a Occidental, pero a la izquierda se ve mal y a la > derecha se ve bien. > Si modifico en el codigo por ó ahi se ve bien, pero en otros combos no... > como puedo hacer que en ese tpl se vea bien sin modificarlo desde el codigo. > Gracias > > Lorenita Ing. Electrónica U. Bosque Ing. de Sistemas U. Bosque > Especialista en Telecomunicaciones Móviles U.Distrital > > > Please use English. But translated by GMail ... "Hi all I have a form that has two panels (. Tpl) which handles variables that come setVariable php function, but I panel menu loads correctly and the right accents to me like a diamond loaded with question marks. Firefox and probe handling changing the charset of UTF-8 to Western, but the left is wrong and right is right. If I edit in the code or there is fine, but in other combos do not ... as I can do that in the tpl look good without modification from the code. Thanks Electronics Engineer Lorenita U. Systems Engineer Forest U. Mobile Specialist Forest U. District " Are both TPL files encoded to use UTF-8? PHP will not convert the encoding of a file automatically. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Acentos en tpl
On 18/03/2011 10:34, Richard Quadling wrote: > 2011/3/17 Lorena Monroy O. : >> Hola a todos >> Tengo un formulario que tiene dos paneles (.tpl), el cual maneja variables >> que vienen de php con la funcion setVariable, pero en el panel del menu me >> carga las tildes correctamente y a la derecha me las carga como un rombo con >> interrogación. Manejo Firefox y probe cambiando la configuración de >> caracteres de UTF-8 a Occidental, pero a la izquierda se ve mal y a la >> derecha se ve bien. >> Si modifico en el codigo por ó ahi se ve bien, pero en otros combos no... >> como puedo hacer que en ese tpl se vea bien sin modificarlo desde el codigo. >> Gracias >> >> Lorenita Ing. Electrónica U. Bosque Ing. de Sistemas U. Bosque >> Especialista en Telecomunicaciones Móviles U.Distrital >> >> >> > > Please use English. > > But translated by GMail ... > > "Hi all > I have a form that has two panels (. Tpl) which handles variables that > come setVariable php function, but I panel menu loads correctly and > the right accents to me like a diamond loaded with question marks. > Firefox and probe handling changing the charset of UTF-8 to Western, > but the left is wrong and right is right. > If I edit in the code or there is fine, but in other combos do not ... > as I can do that in the tpl look good without modification from the > code. > Thanks > > Electronics Engineer Lorenita U. Systems Engineer Forest U. Mobile > Specialist Forest U. District > " > > Are both TPL files encoded to use UTF-8? PHP will not convert the > encoding of a file automatically. > Hi, Also make sure the web server is sending out the correct character encoding. With Apache this can be done by adding the following line to the httpd.conf file and restarting the service: AddDefaultCharset UTF-8 Regards Ian -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RES: [PHP] Acentos en tpl
Lorena : Yo trabajo con idioma portugués y utilizo esto en mi código : http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="pt-br" lang="pt-br"> ... Nunca e tenido problemas con caracteres especiales como é o ú. Y utilizo varios .tpl, deves fijarte en los .tpl para saber qual Content-Type estan utilizando. Otra cosa importante es saber si la información viene de una base de datos, y si esta utiliza LATIN1 como conjunto de caracteres o UTF-8. Para hacer las conversiones que fueren precisas Alejandro M.S. English version: Lorena : I work with portugues and use this in my code : http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="pt-br" lang="pt-br"> ... I never have problems with special characters like é or ú. I use some .tpl, you have to look at .tpl to know what Content-Type the file are using. Other important thing if to know if the information is coming from the database, and if is using LATIN1 CHARACTER SET or UTF-8. To do the conversions that are needed. Alejandro M.S. -Mensagem original- De: Lorena Monroy O. [mailto:lorenamon...@yahoo.com] Enviada em: quinta-feira, 17 de março de 2011 12:55 Para: php-general@lists.php.net Assunto: [PHP] Acentos en tpl Hola a todos Tengo un formulario que tiene dos paneles (.tpl), el cual maneja variables que vienen de php con la funcion setVariable, pero en el panel del menu me carga las tildes correctamente y a la derecha me las carga como un rombo con interrogación. Manejo Firefox y probe cambiando la configuración de caracteres de UTF-8 a Occidental, pero a la izquierda se ve mal y a la derecha se ve bien. Si modifico en el codigo por ó ahi se ve bien, pero en otros combos no... como puedo hacer que en ese tpl se vea bien sin modificarlo desde el codigo. Gracias Lorenita Ing. Electrónica U. Bosque Ing. de Sistemas U. Bosque Especialista en Telecomunicaciones Móviles U.Distrital -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Acentos en tpl
2011/3/18 Alejandro Michelin Salomon : > Lorena : > > Yo trabajo con idioma portugués y utilizo esto en mi código : > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > http://www.w3.org/1999/xhtml"; xml:lang="pt-br" lang="pt-br"> > > > /> > > > ... > > Nunca e tenido problemas con caracteres especiales como é o ú. > Y utilizo varios .tpl, deves fijarte en los .tpl para saber qual > Content-Type estan utilizando. > > Otra cosa importante es saber si la información viene de una base de datos, > y si esta utiliza LATIN1 como conjunto > de caracteres o UTF-8. Para hacer las conversiones que fueren precisas > > Alejandro M.S. > > English version: > Lorena : > > I work with portugues and use this in my code : > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > http://www.w3.org/1999/xhtml"; xml:lang="pt-br" lang="pt-br"> > > > /> > > > ... > > I never have problems with special characters like é or ú. > I use some .tpl, you have to look at .tpl to know what Content-Type the file > are using. > > Other important thing if to know if the information is coming from the > database, and if is using LATIN1 CHARACTER SET > or UTF-8. To do the conversions that are needed. > > Alejandro M.S. > > > -Mensagem original- > De: Lorena Monroy O. [mailto:lorenamon...@yahoo.com] > Enviada em: quinta-feira, 17 de março de 2011 12:55 > Para: php-general@lists.php.net > Assunto: [PHP] Acentos en tpl > > Hola a todos > Tengo un formulario que tiene dos paneles (.tpl), el cual maneja variables > que vienen de php con la funcion setVariable, pero en el panel del menu me > carga las tildes correctamente y a la derecha me las carga como un rombo con > interrogación. Manejo Firefox y probe cambiando la configuración de > caracteres de UTF-8 a Occidental, pero a la izquierda se ve mal y a la > derecha se ve bien. > Si modifico en el codigo por ó ahi se ve bien, pero en otros combos > no... como puedo hacer que en ese tpl se vea bien sin modificarlo desde el > codigo. > Gracias > > Lorenita Ing. Electrónica U. Bosque Ing. de Sistemas U. Bosque > Especialista en Telecomunicaciones Móviles U.Distrital > > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Are you able to zip the 2 templates? I'm guessing your editor is saving one in UTF-8 and the other in the codepage format. >From what I understand, it is better to have everything UTF-8. Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Can´t upload files bigger than 50KB
I could not find the solution to the problem. I've finally solved by using an applet that uploads the files by FTP. In case anyone needs it, the applet I've used is http://sourceforge.net/projects/zupload For me it was the solution! 2011/3/9 Jim Lucas > On 3/9/2011 6:28 AM, Gotzon Astondoa wrote: > > Hi all: > > > > On my website I have an Ajax form. From this form user can upload files. > > My guess would be that you have an HTML form. Not AJAX > > > Server side is a PHP script. > > This form works properly on my development server. > > Is this on localhost or is it remote too? > > > But when I uploaded my application to the definitive server I discovered > > that I can only upload files less than 50KB (It works perfectly with 1 to > 20 > > KB images). > > Silly question, how long does it take for these 1 to 20 KB files to upload? > > > These are the data from the server configuration that I believe can > affect: > > > > post_max_size 8M > > upload_max_filesize 2M > > memory_limit 128M > > safe_mode off > > SELinux disabled > > open_basedir none > > > > I´m now making tests with 52KB image: image.jpg > > I discovered that the uploaded file is uploaded to /tmp. This file name > is > > php10tfTp. > > how much space is free on the partition that contains /tmp ? > > > But the file is not completely uploaded! So, my PHP script is not fired! > > The original image size is 52KB and the new file size is 35KB . I > download > > the tmp file and rename it to php10tfTp.jpg. I can see that half frame is > > the same as the original and the other half is gray. > > > > Any idea what is happening? > > > > Thanks in advance. > > > >
Re: [PHP] PHP session replication
At 3:18 PM + 3/17/11, Stuart Dallas wrote: > Pragmatically speaking though, I'd say go for database backed sessions until > they actually become a performance bottleneck. -snip- This may also be of interest: http://stut.net/2008/07/26/sessionless-sessions-2/ -Stuart -- Stuart Dallas Stuart: I'm not getting the reason for storing a session in a db. In the scripts I have written that remember the user (i.e., "Hi Stuart"), I simply use a cookie stored on the user's computer. Sometimes it's just their name and other times it could be what/where they visited, or how they set their defaults, or any number of things. But everything that is needed and doesn't require authorization is set in a cookie that expires within a specific length of time -- usually a year. I don't see a need for storing session in the above case. If the scripts require an authorization, then I use sessions and a timer in concert. As long as the authorized user remains logged-in and the visit remains active, then the user enjoys the benefits of the visit. If the authorized user times out, then the session is destroyed and the user is asked to log-in again, generating another session. If the authorized user leaves the session (closes the browser) then everything is closed (session destroyed) and sometimes a cookie remains on the user's computer preparing for the next visit. The next time the user visits the site, everything (if anything) that is stored in user's cookie is addressed. But the user is asked to log-in again and another session is generated. In all cases where there is sensitive data, the user must log-in generating a new session. Again, I don't see how storing the current/past session provides any benefit. So, what am I not understanding or missing? Please show me how reactivating (if that is what this is) a session does anything. Thanks, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
Hi Tedd, Long time no chat, hope you're well. On Friday, 18 March 2011 at 15:44, tedd wrote: > At 3:18 PM + 3/17/11, Stuart Dallas wrote: > > > > > Pragmatically speaking though, I'd say go for database backed > > sessions until > > > they actually become a performance bottleneck. > > -snip- > > > > This may also be of interest: > > http://stut.net/2008/07/26/sessionless-sessions-2/ > > -Stuart > > > > -- > > Stuart Dallas > > Stuart: > > I'm not getting the reason for storing a session in a db. If your site is being served by multiple servers you need centralised storage of session data rather than the PHP default of using files. Either that or the load balancer needs to use sticky sessions which can lead to other issues depending on your traffic patterns. My alternative to that is to bounce the minimum amount of data necessary between the browser and server with each request. > In the scripts I have written that remember the user (i.e., "Hi > Stuart"), I simply use a cookie stored on the user's computer. > Sometimes it's just their name and other times it could be what/where > they visited, or how they set their defaults, or any number of > things. But everything that is needed and doesn't require > authorization is set in a cookie that expires within a specific > length of time -- usually a year. > > I don't see a need for storing session in the above case. That would be because there isn't one, but you'd be surprised how often sessions are used for this type of thing. > If the scripts require an authorization, then I use sessions and a > timer in concert. As long as the authorized user remains logged-in > and the visit remains active, then the user enjoys the benefits of > the visit. > > If the authorized user times out, then the session is destroyed and > the user is asked to log-in again, generating another session. > > If the authorized user leaves the session (closes the browser) then > everything is closed (session destroyed) and sometimes a cookie > remains on the user's computer preparing for the next visit. > > The next time the user visits the site, everything (if anything) that > is stored in user's cookie is addressed. But the user is asked to > log-in again and another session is generated. > > In all cases where there is sensitive data, the user must log-in > generating a new session. > > Again, I don't see how storing the current/past session provides any benefit. > > So, what am I not understanding or missing? > > Please show me how reactivating (if that is what this is) a session > does anything. I don't recall anyone saying anything about reactivating old sessions. The cookies I use to replace sessions are session-based cookies and last no longer than a traditional PHP session. The key is to provide a lightweight method of ensuring that whichever server processes the request has access to the session data. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
At 3:53 PM + 3/18/11, Stuart Dallas wrote: Hi Tedd, Long time no chat, hope you're well. On Friday, 18 March 2011 at 15:44, tedd wrote: At 3:18 PM + 3/17/11, Stuart Dallas wrote: > > > Pragmatically speaking though, I'd say go for database backed > sessions until > > they actually become a performance bottleneck. > -snip- > > This may also be of interest: > http://stut.net/2008/07/26/sessionless-sessions-2/ > -Stuart > > -- > Stuart Dallas Stuart: I'm not getting the reason for storing a session in a db. If your site is being served by multiple servers you need centralised storage of session data rather than the PHP default of using files. Either that or the load balancer needs to use sticky sessions which can lead to other issues depending on your traffic patterns. My alternative to that is to bounce the minimum amount of data necessary between the browser and server with each request. In the scripts I have written that remember the user (i.e., "Hi Stuart"), I simply use a cookie stored on the user's computer. Sometimes it's just their name and other times it could be what/where they visited, or how they set their defaults, or any number of things. But everything that is needed and doesn't require authorization is set in a cookie that expires within a specific length of time -- usually a year. I don't see a need for storing session in the above case. That would be because there isn't one, but you'd be surprised how often sessions are used for this type of thing. If the scripts require an authorization, then I use sessions and a timer in concert. As long as the authorized user remains logged-in and the visit remains active, then the user enjoys the benefits of the visit. If the authorized user times out, then the session is destroyed and the user is asked to log-in again, generating another session. If the authorized user leaves the session (closes the browser) then everything is closed (session destroyed) and sometimes a cookie remains on the user's computer preparing for the next visit. The next time the user visits the site, everything (if anything) that is stored in user's cookie is addressed. But the user is asked to log-in again and another session is generated. In all cases where there is sensitive data, the user must log-in generating a new session. Again, I don't see how storing the current/past session provides any benefit. So, what am I not understanding or missing? Please show me how reactivating (if that is what this is) a session does anything. I don't recall anyone saying anything about reactivating old sessions. The cookies I use to replace sessions are session-based cookies and last no longer than a traditional PHP session. The key is to provide a lightweight method of ensuring that whichever server processes the request has access to the session data. -Stuart Thanks Stuart. You are always a couple of light years ahead of me. I'll have to study what you provided. Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
Hello First you need to decide which type of cluster you choose. If you use LVS you can tell the director do bind one client to one server so you do not need to replicat session. If you choose DNS for load balancing you should replicat the session by database or DRBD or memcache server. Also transfer the session id in the browser URL and not by cookie. BR/Torsten "tedd" schrieb: >At 3:53 PM + 3/18/11, Stuart Dallas wrote: >>Hi Tedd, >> >>Long time no chat, hope you're well. >> >>On Friday, 18 March 2011 at 15:44, tedd wrote: >>> At 3:18 PM + 3/17/11, Stuart Dallas wrote: >>> > >>> > > Pragmatically speaking though, I'd say go for database backed >>> > sessions until >>> > > they actually become a performance bottleneck. >>> > -snip- >>> > >>> > This may also be of interest: >>> > http://stut.net/2008/07/26/sessionless-sessions-2/ >>> > -Stuart >>> > >>> > -- >>> > Stuart Dallas >>> >>> Stuart: >>> >>> I'm not getting the reason for storing a session in a db. >> >>If your site is being served by multiple servers you need >>centralised storage of session data rather than the PHP default of >>using files. Either that or the load balancer needs to use sticky >>sessions which can lead to other issues depending on your traffic >>patterns. >> >>My alternative to that is to bounce the minimum amount of data >>necessary between the browser and server with each request. >> >>> In the scripts I have written that remember the user (i.e., "Hi >>> Stuart"), I simply use a cookie stored on the user's computer. >>> Sometimes it's just their name and other times it could be what/where >>> they visited, or how they set their defaults, or any number of >>> things. But everything that is needed and doesn't require >>> authorization is set in a cookie that expires within a specific >>> length of time -- usually a year. >>> >>> I don't see a need for storing session in the above case. >> >>That would be because there isn't one, but you'd be surprised how >>often sessions are used for this type of thing. >> >>> If the scripts require an authorization, then I use sessions and a >>> timer in concert. As long as the authorized user remains logged-in >>> and the visit remains active, then the user enjoys the benefits of >>> the visit. >>> >>> If the authorized user times out, then the session is destroyed and >>> the user is asked to log-in again, generating another session. >>> >>> If the authorized user leaves the session (closes the browser) then >>> everything is closed (session destroyed) and sometimes a cookie >>> remains on the user's computer preparing for the next visit. >>> >>> The next time the user visits the site, everything (if anything) that >>> is stored in user's cookie is addressed. But the user is asked to >>> log-in again and another session is generated. >>> >>> In all cases where there is sensitive data, the user must log-in >>> generating a new session. >>> >>> Again, I don't see how storing the current/past session provides >>>any benefit. >>> >>> So, what am I not understanding or missing? >>> >>> Please show me how reactivating (if that is what this is) a session >>> does anything. >> >>I don't recall anyone saying anything about reactivating old >>sessions. The cookies I use to replace sessions are session-based >>cookies and last no longer than a traditional PHP session. The key >>is to provide a lightweight method of ensuring that whichever server >>processes the request has access to the session data. >> >>-Stuart > > >Thanks Stuart. > >You are always a couple of light years ahead of me. I'll have to >study what you provided. > >Cheers, > >tedd > >-- >--- >http://sperling.com/ > >-- >PHP General Mailing List (http://www.php.net/) >To unsubscribe, visit: http://www.php.net/unsub.php > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
On Friday, 18 March 2011 at 16:19, Torsten Rosenberger wrote: Hello > > First you need to decide which type of cluster you choose. If you use LVS you > can tell the director do bind one client to one server so you do not need to > replicat session. As I said in my response to Tedd, binding clients to servers can cause problems because you might end up with a bunch of resource-intensive users being locked to a single server when other servers are sitting there practically idle. Load balancers perform best when they are not restricted in this way. > If you choose DNS for load balancing you should replicat the session by > database or DRBD or memcache server. Also transfer the session id in the > browser URL and not by cookie. First of all I would personally slap anyone I work with for suggesting that we use DNS for load balancing. Secondly, the only mechanism you've mentioned that is replicating rather than centralising the session is DRBD. And finally, why do any of these mechanisms require passing the ID in the URL rather than a cookie? I'm curious to know what people are storing in their sessions. Is there anything larger than a few hundred bytes that is specific and unique to that session storage? What are the use cases for server-side session storage because it seems like I'm missing something? -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ > BR/Torsten > > > "tedd" schrieb: > > > At 3:53 PM + 3/18/11, Stuart Dallas wrote: > > > Hi Tedd, > > > > > > Long time no chat, hope you're well. > > > > > > On Friday, 18 March 2011 at 15:44, tedd wrote: > > > > At 3:18 PM + 3/17/11, Stuart Dallas wrote: > > > > > > > > > > > Pragmatically speaking though, I'd say go for database backed > > > > > sessions until > > > > > > they actually become a performance bottleneck. > > > > > -snip- > > > > > > > > > > This may also be of interest: > > > > > http://stut.net/2008/07/26/sessionless-sessions-2/ > > > > > -Stuart > > > > > > > > > > -- > > > > > Stuart Dallas > > > > > > > > Stuart: > > > > > > > > I'm not getting the reason for storing a session in a db. > > > > > > If your site is being served by multiple servers you need > > > centralised storage of session data rather than the PHP default of > > > using files. Either that or the load balancer needs to use sticky > > > sessions which can lead to other issues depending on your traffic > > > patterns. > > > > > > My alternative to that is to bounce the minimum amount of data > > > necessary between the browser and server with each request. > > > > > > > In the scripts I have written that remember the user (i.e., "Hi > > > > Stuart"), I simply use a cookie stored on the user's computer. > > > > Sometimes it's just their name and other times it could be what/where > > > > they visited, or how they set their defaults, or any number of > > > > things. But everything that is needed and doesn't require > > > > authorization is set in a cookie that expires within a specific > > > > length of time -- usually a year. > > > > > > > > I don't see a need for storing session in the above case. > > > > > > That would be because there isn't one, but you'd be surprised how > > > often sessions are used for this type of thing. > > > > > > > If the scripts require an authorization, then I use sessions and a > > > > timer in concert. As long as the authorized user remains logged-in > > > > and the visit remains active, then the user enjoys the benefits of > > > > the visit. > > > > > > > > If the authorized user times out, then the session is destroyed and > > > > the user is asked to log-in again, generating another session. > > > > > > > > If the authorized user leaves the session (closes the browser) then > > > > everything is closed (session destroyed) and sometimes a cookie > > > > remains on the user's computer preparing for the next visit. > > > > > > > > The next time the user visits the site, everything (if anything) that > > > > is stored in user's cookie is addressed. But the user is asked to > > > > log-in again and another session is generated. > > > > > > > > In all cases where there is sensitive data, the user must log-in > > > > generating a new session. > > > > > > > > Again, I don't see how storing the current/past session provides > > > > any benefit. > > > > > > > > So, what am I not understanding or missing? > > > > > > > > Please show me how reactivating (if that is what this is) a session > > > > does anything. > > > > > > I don't recall anyone saying anything about reactivating old > > > sessions. The cookies I use to replace sessions are session-based > > > cookies and last no longer than a traditional PHP session. The key > > > is to provide a lightweight method of ensuring that whichever server > > > processes the request has access to the session data. > > > > > > -Stuart > > > > > > Thanks Stuart. > > > > You are always a couple of light years ahead
Re: [PHP] PHP session replication
"Stuart Dallas" schrieb: >On Friday, 18 March 2011 at 16:19, Torsten Rosenberger wrote: >Hello >> >> First you need to decide which type of cluster you choose. If you use LVS >> you can tell the director do bind one client to one server so you do not >> need to replicat session. > >As I said in my response to Tedd, binding clients to servers can cause >problems because you might end up with a bunch of resource-intensive users >being locked to a single server when other servers are sitting there >practically idle. Load balancers perform best when they are not restricted in >this way. > >> If you choose DNS for load balancing you should replicat the session by >> database or DRBD or memcache server. Also transfer the session id in the >> browser URL and not by cookie. > >First of all I would personally slap anyone I work with for suggesting that we >use DNS for load balancing. > >Secondly, the only mechanism you've mentioned that is replicating rather than >centralising the session is DRBD. And finally, why do any of these mechanisms >require passing the ID in the URL rather than a cookie? There is no need for the mechanism right. > >I'm curious to know what people are storing in their sessions. Is there >anything larger than a few hundred bytes that is specific and unique to that >session storage? What are the use cases for server-side session storage >because it seems like I'm missing something? I store user rights in the session but also possible to do it with a DB query every time. I start reading this thread in the middle. So how big should this project how many requests/sec Tedd? BR/Torsten -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: > "Stuart Dallas" schrieb: > > > On Friday, 18 March 2011 at 16:19, Torsten Rosenberger wrote: > > Hello > > > > > > First you need to decide which type of cluster you choose. If you use LVS > > > you can tell the director do bind one client to one server so you do not > > > need to replicat session. > > > > As I said in my response to Tedd, binding clients to servers can cause > > problems because you might end up with a bunch of resource-intensive users > > being locked to a single server when other servers are sitting there > > practically idle. Load balancers perform best when they are not restricted > > in this way. > > > > > If you choose DNS for load balancing you should replicat the session by > > > database or DRBD or memcache server. Also transfer the session id in the > > > browser URL and not by cookie. > > > > First of all I would personally slap anyone I work with for suggesting that > > we use DNS for load balancing. > > > > Secondly, the only mechanism you've mentioned that is replicating rather > > than centralising the session is DRBD. And finally, why do any of these > > mechanisms require passing the ID in the URL rather than a cookie? > There is no need for the mechanism right. So why do you suggest not using cookies? > > > > I'm curious to know what people are storing in their sessions. Is there > > anything larger than a few hundred bytes that is specific and unique to > > that session storage? What are the use cases for server-side session > > storage because it seems like I'm missing something? > > I store user rights in the session but also possible to do it with a DB query > every time. Why not store those in an encrypted cookie? Unless we're talking about more than a couple of hundred bytes I see no reason to store them separately server-side or to hit the DB each time. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] designing a post fix
In this case, I would take a look at dbmail (dbmail.org) It uses a SQL backend for storing messages and users. If you're just sending mail locally, but use the tables, etc. You'll need to build your own frontend, but you could use something like RoundCube or Squirrelmail to talk to it. I still like my Zimbra server idea, better for this. --Curtis Stuart Dallas wrote: > On Thursday, 17 March 2011 at 16:56, Negin Nickparsa wrote: > internal messaging system > > In that case it's simply a matter of creating a table structure to hold > the messages and building an interface that will display them and allow > new messages to be added, probably with email-based notifications. This is > fairly straightforward stuff, you just need to think about the elements > that make up a message, convert that list into a table structure, add some > metadata for unread, etc. > > > -Stuart > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ > > >> On Thu, Mar 17, 2011 at 8:16 PM, Stuart Dallas wrote: >> > On Thursday, 17 March 2011 at 15:23, Negin Nickparsa wrote: >> > i want 2 design a php web for staff members that can sign in with >> > > their accounts n then mail 2 each other i don't know how it really >> > > works by using a mail server i'm beginner at it! but i studied alot >> > > abt it. >> > >> > Are you talking about interfacing with email, or an internal messaging >> system? >> > >> > >> > -Stuart >> > >> > -- >> > Stuart Dallas >> > 3ft9 Ltd >> > http://3ft9.com/ >> > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] designing a post fix
I would suggest Zimbra. It just gets it done. Run it on Ubuntu Server or CentOS. --Curtis Negin Nickparsa wrote: > I'm Negin > what is Squirrel Mail ? > On Thu, Mar 17, 2011 at 7:55 PM, NetEmp wrote: >> @Nergin: are you trying to create an application like Squirrel Mail >> using >> PHP? >> >> On Thu, Mar 17, 2011 at 9:46 PM, Jason Pruim >> >> wrote: >>> >>> So what exactly is the question? >>> >>> >>> Jason Pruim >>> >>> On Mar 17, 2011, at 11:23 AM, Negin Nickparsa >>> wrote: >>> >>> > i want 2 design a php web for staff members that can sign in with >>> > their accounts n then mail 2 each other i don't know how it really >>> > works by using a mail server i'm beginner at it! but i studied alot >>> > abt it. >>> > >>> > -- >>> > PHP General Mailing List (http://www.php.net/) >>> > To unsubscribe, visit: http://www.php.net/unsub.php >>> > >>> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >> > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] designing a post fix
Zimbra Server. Negin Nickparsa wrote: > :( maybe it's ticketing i don't know exactly!!!:"( > here are the things that i must do: > > receiving mails and return of mails > showing emails 2 staff > when a mail received it can be viewed in a moment(like ajax) > drafts and upload and download from mail > determine mails due on > mails that replied and can be closed > searching special mail or special person > attachments > forwardings > digital signature(I know this one is very difficult! 98% I will ignore > this part) > management of meetings and calendar in my language! > private messaging > a period time for a reply of a mail (after time if it didn’t have > reply then close it) > settings for users > sending sms to that user when priod time is going 2 finish > making priority for emergency mails > > On Thu, Mar 17, 2011 at 9:21 PM, Negin Nickparsa > wrote: >> ok! stuart plz let me think to exactly tell u what i want! because i >> must make sentences more clear i know i have bad english sorry! >> i will tell u in a moment. >> > >> On Thu, Mar 17, 2011 at 9:16 PM, Stuart Dallas wrote: >>> On Thursday, 17 March 2011 at 17:25, Negin Nickparsa wrote: >>> but yes i need notifications now we use free application named osticket but it doesn't work very well I can change my codes because i have time what is your suggestion for me which one can better support my site? MTA or another free app? >>> >>> Negin, this is starting to become a conversation I usually charge for! >>> If you need help spec'ing and/or building a system I may be able to >>> help, but at the moment I'm unclear exactly what problem you're trying >>> to solve. If you need an email solution I suggest you use Google Apps. >>> If you need a ticketing system then there are lots of good options in >>> that area, and personally I think it would be a waste of effort to >>> start from scratch. If neither of those are what you're after, then I'm >>> lost. >>> >>> >>> -Stuart >>> >>> -- >>> Stuart Dallas >>> 3ft9 Ltd >>> http://3ft9.com/ >>> >>> On Thu, Mar 17, 2011 at 8:43 PM, Negin Nickparsa wrote: > when a user will be logged on he/she must have the messages just for > him self yeah? then i must have a column for the mails that he > recieved > 4 example select mail1 from users where user=user1 > > i got it right? > > On Thu, Mar 17, 2011 at 8:39 PM, Negin Nickparsa wrote: > > u mean i can have localhost mail service or not? > > > > On Thu, Mar 17, 2011 at 8:36 PM, Negin Nickparsa wrote: > > > i'll give all my users user n password will they be under the same > > > domain or not? > > > user1 has the domain gmail n user 2 ymail > > > or i can have all users the same thing like dpaco.net > > > this is our site==>dpaco.net > > > i want to build another part of it with php > > > > > > On Thu, Mar 17, 2011 at 8:30 PM, Stuart Dallas wrote: > > > > On Thursday, 17 March 2011 at 16:56, Negin Nickparsa wrote: > > > > internal messaging system > > > > > > > > In that case it's simply a matter of creating a table structure to hold the messages and building an interface that will display them and allow new messages to be added, probably with email-based notifications. This is fairly straightforward stuff, you just need to think about the elements that make up a message, convert that list into a table structure, add some metadata for unread, etc. > > > > > > > > > > > > -Stuart > > > > > > > > -- > > > > Stuart Dallas > > > > 3ft9 Ltd > > > > http://3ft9.com/ > > > > > > > > > > > > > On Thu, Mar 17, 2011 at 8:16 PM, Stuart Dallas wrote: > > > > > > On Thursday, 17 March 2011 at 15:23, Negin Nickparsa wrote: > > > > > > i want 2 design a php web for staff members that can sign in with > > > > > > > their accounts n then mail 2 each other i don't know how it really > > > > > > > works by using a mail server i'm beginner at it! but i studied alot > > > > > > > abt it. > > > > > > > > > > > > Are you talking about interfacing with email, or an internal messaging system? > > > > > > > > > > > > > > > > > > -Stuart > > > > > > > > > > > > -- > > > > > > Stuart Dallas > > > > > > 3ft9 Ltd > > > > > > http://3ft9.com/ >>> >>> >> > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] designing a post fix
can u explain zimbra server 4 me? On Thu, Mar 17, 2011 at 9:44 PM, Curtis Maurand wrote: > > Zimbra Server. > > Negin Nickparsa wrote: >> :( maybe it's ticketing i don't know exactly!!!:"( >> here are the things that i must do: >> >> receiving mails and return of mails >> showing emails 2 staff >> when a mail received it can be viewed in a moment(like ajax) >> drafts and upload and download from mail >> determine mails due on >> mails that replied and can be closed >> searching special mail or special person >> attachments >> forwardings >> digital signature(I know this one is very difficult! 98% I will ignore >> this part) >> management of meetings and calendar in my language! >> private messaging >> a period time for a reply of a mail (after time if it didn’t have >> reply then close it) >> settings for users >> sending sms to that user when priod time is going 2 finish >> making priority for emergency mails >> >> On Thu, Mar 17, 2011 at 9:21 PM, Negin Nickparsa >> wrote: >>> ok! stuart plz let me think to exactly tell u what i want! because i >>> must make sentences more clear i know i have bad english sorry! >>> i will tell u in a moment. >>> >> >>> On Thu, Mar 17, 2011 at 9:16 PM, Stuart Dallas wrote: On Thursday, 17 March 2011 at 17:25, Negin Nickparsa wrote: but yes i need notifications > now we use free application named osticket but it doesn't work very > well > I can change my codes because i have time > what is your suggestion for me which one can better support my site? > MTA or another free app? Negin, this is starting to become a conversation I usually charge for! If you need help spec'ing and/or building a system I may be able to help, but at the moment I'm unclear exactly what problem you're trying to solve. If you need an email solution I suggest you use Google Apps. If you need a ticketing system then there are lots of good options in that area, and personally I think it would be a waste of effort to start from scratch. If neither of those are what you're after, then I'm lost. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ > On Thu, Mar 17, 2011 at 8:43 PM, Negin Nickparsa > wrote: > > when a user will be logged on he/she must have the messages just for > > him self yeah? then i must have a column for the mails that he > > recieved > > 4 example select mail1 from users where user=user1 > > > > i got it right? > > > > On Thu, Mar 17, 2011 at 8:39 PM, Negin Nickparsa > wrote: > > > u mean i can have localhost mail service or not? > > > > > > On Thu, Mar 17, 2011 at 8:36 PM, Negin Nickparsa > wrote: > > > > i'll give all my users user n password will they be under the > same > > > > domain or not? > > > > user1 has the domain gmail n user 2 ymail > > > > or i can have all users the same thing like dpaco.net > > > > this is our site==>dpaco.net > > > > i want to build another part of it with php > > > > > > > > On Thu, Mar 17, 2011 at 8:30 PM, Stuart Dallas > wrote: > > > > > On Thursday, 17 March 2011 at 16:56, Negin Nickparsa wrote: > > > > > internal messaging system > > > > > > > > > > In that case it's simply a matter of creating a table > structure to hold the messages and building an interface that > will display them and allow new messages to be added, probably > with email-based notifications. This is fairly straightforward > stuff, you just need to think about the elements that make up > a message, convert that list into a table structure, add some > metadata for unread, etc. > > > > > > > > > > > > > > > -Stuart > > > > > > > > > > -- > > > > > Stuart Dallas > > > > > 3ft9 Ltd > > > > > http://3ft9.com/ > > > > > > > > > > > > > > > > On Thu, Mar 17, 2011 at 8:16 PM, Stuart Dallas > wrote: > > > > > > > On Thursday, 17 March 2011 at 15:23, Negin Nickparsa > wrote: > > > > > > > i want 2 design a php web for staff members that can sign > in with > > > > > > > > their accounts n then mail 2 each other i don't know how > it really > > > > > > > > works by using a mail server i'm beginner at it! but i > studied alot > > > > > > > > abt it. > > > > > > > > > > > > > > Are you talking about interfacing with email, or an > internal messaging system? > > > > > > > > > > > > > > > > > > > > > -Stuart > > > > > > > > > > > > > > -- > > > > > > > Stuart Dallas > > > > > > > 3ft9 Ltd > > > > > > > http://3ft9.com/ > >>> >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas wrote: > On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: > > > I'm curious to know what people are storing in their sessions. Is there > anything larger than a few hundred bytes that is specific and unique to that > session storage? What are the use cases for server-side session storage > because it seems like I'm missing something? > > > > I store user rights in the session but also possible to do it with a DB > query every time. > > Why not store those in an encrypted cookie? Unless we're talking about more > than a couple of hundred bytes I see no reason to store them separately > server-side or to hit the DB each time. Stuart, would you not agree that sending any amount of data over the wire takes more time than passing it over an internal network? From my perspective the tradeoffs of cookies vs. server side session storage are application performance and cost of ownership. An application will be more responsive if less data is sent over the wire on each request however running a distributed session store on the server side can be expensive monetarily. Storing session data in cookies has it's merits, but I think they start to loose their benefits on large sites. The way I see it they can be a great way to cope with startup costs and server-side complexity on low traffic sites. -nathan
Re: [PHP] designing a post fix
Its a free exchange server replacement. It has shared folders, shared documents, email, calendars, shared calendars, notifications, etc. etc. etc. http://www.zimbra.com --Curtis Negin Nickparsa wrote: > can u explain zimbra server 4 me? > > On Thu, Mar 17, 2011 at 9:44 PM, Curtis Maurand > wrote: >> >> Zimbra Server. >> >> Negin Nickparsa wrote: >>> :( maybe it's ticketing i don't know exactly!!!:"( >>> here are the things that i must do: >>> >>> receiving mails and return of mails >>> showing emails 2 staff >>> when a mail received it can be viewed in a moment(like ajax) >>> drafts and upload and download from mail >>> determine mails due on >>> mails that replied and can be closed >>> searching special mail or special person >>> attachments >>> forwardings >>> digital signature(I know this one is very difficult! 98% I will ignore >>> this part) >>> management of meetings and calendar in my language! >>> private messaging >>> a period time for a reply of a mail (after time if it didn’t have >>> reply then close it) >>> settings for users >>> sending sms to that user when priod time is going 2 finish >>> making priority for emergency mails >>> >>> On Thu, Mar 17, 2011 at 9:21 PM, Negin Nickparsa >>> wrote: ok! stuart plz let me think to exactly tell u what i want! because i must make sentences more clear i know i have bad english sorry! i will tell u in a moment. >>> On Thu, Mar 17, 2011 at 9:16 PM, Stuart Dallas wrote: > On Thursday, 17 March 2011 at 17:25, Negin Nickparsa wrote: > but yes i need notifications >> now we use free application named osticket but it doesn't work very >> well >> I can change my codes because i have time >> what is your suggestion for me which one can better support my site? >> MTA or another free app? > > Negin, this is starting to become a conversation I usually charge > for! > If you need help spec'ing and/or building a system I may be able to > help, but at the moment I'm unclear exactly what problem you're > trying > to solve. If you need an email solution I suggest you use Google > Apps. > If you need a ticketing system then there are lots of good options in > that area, and personally I think it would be a waste of effort to > start from scratch. If neither of those are what you're after, then > I'm > lost. > > > -Stuart > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ > > >> On Thu, Mar 17, 2011 at 8:43 PM, Negin Nickparsa >> >> wrote: >> > when a user will be logged on he/she must have the messages just >> for >> > him self yeah? then i must have a column for the mails that he >> > recieved >> > 4 example select mail1 from users where user=user1 >> > >> > i got it right? >> > >> > On Thu, Mar 17, 2011 at 8:39 PM, Negin Nickparsa >> wrote: >> > > u mean i can have localhost mail service or not? >> > > >> > > On Thu, Mar 17, 2011 at 8:36 PM, Negin Nickparsa >> wrote: >> > > > i'll give all my users user n password will they be under the >> same >> > > > domain or not? >> > > > user1 has the domain gmail n user 2 ymail >> > > > or i can have all users the same thing like dpaco.net >> > > > this is our site==>dpaco.net >> > > > i want to build another part of it with php >> > > > >> > > > On Thu, Mar 17, 2011 at 8:30 PM, Stuart Dallas >> >> wrote: >> > > > > On Thursday, 17 March 2011 at 16:56, Negin Nickparsa wrote: >> > > > > internal messaging system >> > > > > >> > > > > In that case it's simply a matter of creating a table >> structure to hold the messages and building an interface that >> will display them and allow new messages to be added, probably >> with email-based notifications. This is fairly straightforward >> stuff, you just need to think about the elements that make up >> a message, convert that list into a table structure, add some >> metadata for unread, etc. >> > > > > >> > > > > >> > > > > -Stuart >> > > > > >> > > > > -- >> > > > > Stuart Dallas >> > > > > 3ft9 Ltd >> > > > > http://3ft9.com/ >> > > > > >> > > > > >> > > > > > On Thu, Mar 17, 2011 at 8:16 PM, Stuart Dallas >> wrote: >> > > > > > > On Thursday, 17 March 2011 at 15:23, Negin Nickparsa >> wrote: >> > > > > > > i want 2 design a php web for staff members that can >> sign >> in with >> > > > > > > > their accounts n then mail 2 each other i don't know >> how >> it really >> > > > > > > > works by using a mail server i'm beginner at it! but i >> studied alot >> > > > > > > > abt it. >> > > > > > > >> > > > > > > Are you talking about interfacing with email, or an >> internal messaging system? >> > > > > > > >> > > > > > > >> > > > > > > -Stuart >> > > > > >
Re: [PHP] PHP session replication
On Friday, 18 March 2011 at 17:36, Nathan Nobbe wrote: On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas wrote: > > On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: > > > > I'm curious to know what people are storing in their sessions. Is there > > > > anything larger than a few hundred bytes that is specific and unique to > > > > that session storage? What are the use cases for server-side session > > > > storage because it seems like I'm missing something? > > > > > > I store user rights in the session but also possible to do it with a DB > > > query every time. > > > > Why not store those in an encrypted cookie? Unless we're talking about more > > than a couple of hundred bytes I see no reason to store them separately > > server-side or to hit the DB each time. > > Stuart, would you not agree that sending any amount of data over the wire > takes more time than passing it over an internal network? From my perspective > the tradeoffs of cookies vs. server side session storage are application > performance and cost of ownership. > > An application will be more responsive if less data is sent over the wire on > each request however running a distributed session store on the server side > can be expensive monetarily. Storing session data in cookies has it's merits, > but I think they start to loose their benefits on large sites. The way I see > it they can be a great way to cope with startup costs and server-side > complexity on low traffic sites. Agreed, but how much traffic do you need to be getting for an extra 127 bytes per request to make a noticeable addition to page response times or your bandwidth bill? I just logged in to the main site on which I use this mechanism and checked the headers sent by the browser. This is what got sent... Cookie: t=HgiivpyFIVX62BYIe4PSg4de04I92qTa1aL6yu8vQDI%3D; expires=Sat, 17-Mar-2012 17:39:36 GMT; path=/; domain=example.co.uk That's 126 bytes plus the LF, and that's assuming that your site sets no other cookies. If it does then the extra weight is only 118 bytes. Obviously this varies slightly but essentially we're talking about a very small overhead per request. My strategy specifically aims to limit the amount of data stored in cookies - I don't use sessions to store anything that's not absolutely necessary. I would argue that an application will get more responsive with every server-side shared resource you remove from the equation. Compare the time taken to receive an extra 118 bytes and decrypt that data to the time taken to make a request to a shared data storage system, bearing in mind that such a system will get slower as the number of concurrent requests increases. I agree that for sites with huge amounts of traffic need to look at this type of problem differently, but I think the level at which your perspective changes is very high. The main site on which I use this cookie-based system peaks at ~400 reqs/sec and pushes out just under 1.5TB of HTML per month. I've done the calculations and the cost of maintaining a server-side session store are huge compared to the extra bandwidth used by the cookies. If your app really needs to store large amounts of data in sessions (and I'm yet to have anyone give me a solid example) then the maths will flip and server-side storage becomes the cheaper option. So, in summary, you're right that the data transfer time will be lower server-side, but there are other factors that also need to be considered. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
On 18 March 2011 17:36, Nathan Nobbe wrote: > On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas wrote: > >> On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: >> >> > I'm curious to know what people are storing in their sessions. Is there >> anything larger than a few hundred bytes that is specific and unique to that >> session storage? What are the use cases for server-side session storage >> because it seems like I'm missing something? >> > >> > I store user rights in the session but also possible to do it with a DB >> query every time. >> >> Why not store those in an encrypted cookie? Unless we're talking about more >> than a couple of hundred bytes I see no reason to store them separately >> server-side or to hit the DB each time. > > > Stuart, would you not agree that sending any amount of data over the wire > takes more time than passing it over an internal network? From my > perspective the tradeoffs of cookies vs. server side session storage are > application performance and cost of ownership. > > An application will be more responsive if less data is sent over the wire on > each request however running a distributed session store on the server side > can be expensive monetarily. Storing session data in cookies has it's > merits, but I think they start to loose their benefits on large sites. The > way I see it they can be a great way to cope with startup costs and > server-side complexity on low traffic sites. > > -nathan > The addition of a small cookie would far outweigh all the communication to and from the SQL server (even though it is only memory). Consider that you are going to be getting a session cookie from the client, substituting the cookie for compressed/encrypted data should be very quick. Nothing more than a bit of string manip. The actually traffic for a channel to a SQL db is going to be a little more than a few bytes. All the handshaking and SQL server processing of the SQL statement, the data retrieval and packaging and transmission ... I'd say that for the right circumstances, putting the session data in the cookie would be beneficial. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
On Fri, Mar 18, 2011 at 11:56 AM, Stuart Dallas wrote: > On Friday, 18 March 2011 at 17:36, Nathan Nobbe wrote: > On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas wrote: > > > On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: > > > > > I'm curious to know what people are storing in their sessions. Is > there anything larger than a few hundred bytes that is specific and unique > to that session storage? What are the use cases for server-side session > storage because it seems like I'm missing something? > > > > > > > > I store user rights in the session but also possible to do it with a > DB query every time. > > > > > > Why not store those in an encrypted cookie? Unless we're talking about > more than a couple of hundred bytes I see no reason to store them separately > server-side or to hit the DB each time. > > > > Stuart, would you not agree that sending any amount of data over the wire > takes more time than passing it over an internal network? From my > perspective the tradeoffs of cookies vs. server side session storage are > application performance and cost of ownership. > > > > An application will be more responsive if less data is sent over the wire > on each request however running a distributed session store on the server > side can be expensive monetarily. Storing session data in cookies has it's > merits, but I think they start to loose their benefits on large sites. The > way I see it they can be a great way to cope with startup costs and > server-side complexity on low traffic sites. > > Agreed, but how much traffic do you need to be getting for an extra 127 > bytes per request to make a noticeable addition to page response times or > your bandwidth bill? > > I just logged in to the main site on which I use this mechanism and checked > the headers sent by the browser. This is what got sent... > > Cookie: t=HgiivpyFIVX62BYIe4PSg4de04I92qTa1aL6yu8vQDI%3D; expires=Sat, > 17-Mar-2012 17:39:36 GMT; path=/; domain=example.co.uk > > That's 126 bytes plus the LF, and that's assuming that your site sets no > other cookies. If it does then the extra weight is only 118 bytes. Obviously > this varies slightly but essentially we're talking about a very small > overhead per request. My strategy specifically aims to limit the amount of > data stored in cookies - I don't use sessions to store anything that's not > absolutely necessary. > > I would argue that an application will get more responsive with every > server-side shared resource you remove from the equation. Compare the time > taken to receive an extra 118 bytes and decrypt that data to the time taken > to make a request to a shared data storage system, bearing in mind that such > a system will get slower as the number of concurrent requests increases. > > I agree that for sites with huge amounts of traffic need to look at this > type of problem differently, but I think the level at which your perspective > changes is very high. The main site on which I use this cookie-based system > peaks at ~400 reqs/sec and pushes out just under 1.5TB of HTML per month. > I've done the calculations and the cost of maintaining a server-side session > store are huge compared to the extra bandwidth used by the cookies. > Yes, I think it makes sense to start out storing sessions in cookies and consider a server-side move only when it makes sense. > If your app really needs to store large amounts of data in sessions (and > I'm yet to have anyone give me a solid example) then the maths will flip and > server-side storage becomes the cheaper option. > I worked at a site that is roughly the 25th largest on the net in terms of traffic. This is where I was originally exposed to the tradeoffs of session storage in cookies vs server-side. Until then I presumed things were almost always done server-side. However, if you look at Code Igniter and I'd hazard a guess at a number of other frameworks, the default session store is cookies! This was perplexing until I started to work at the site mentioned above (remains nameless tho:)), where I was actually able to discuss pros & cons thereof. CI seemed to have a problem in that it would not spill data over into additional cookies when the size of one cookie was maxed out. One way to tell it's time to rethink your paradigm is when you're using up the maximum number of cookies for a given domain to propagate data between requests - been there, lol. I'm surprised this concept was such as surprise to many of the list members, I thought this was a well know paradigm, storing session data in cookies. -nathan
Re: [PHP] PHP session replication
On Fri, Mar 18, 2011 at 11:58 AM, Richard Quadling wrote: > On 18 March 2011 17:36, Nathan Nobbe wrote: > > On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas wrote: > > > >> On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: > >> > >> > I'm curious to know what people are storing in their sessions. Is > there > >> anything larger than a few hundred bytes that is specific and unique to > that > >> session storage? What are the use cases for server-side session storage > >> because it seems like I'm missing something? > >> > > >> > I store user rights in the session but also possible to do it with a > DB > >> query every time. > >> > >> Why not store those in an encrypted cookie? Unless we're talking about > more > >> than a couple of hundred bytes I see no reason to store them separately > >> server-side or to hit the DB each time. > > > > > > Stuart, would you not agree that sending any amount of data over the wire > > takes more time than passing it over an internal network? From my > > perspective the tradeoffs of cookies vs. server side session storage are > > application performance and cost of ownership. > > > > An application will be more responsive if less data is sent over the wire > on > > each request however running a distributed session store on the server > side > > can be expensive monetarily. Storing session data in cookies has it's > > merits, but I think they start to loose their benefits on large sites. > The > > way I see it they can be a great way to cope with startup costs and > > server-side complexity on low traffic sites. > > > > -nathan > > > > The addition of a small cookie would far outweigh all the > communication to and from the SQL server (even though it is only > memory). > > Consider that you are going to be getting a session cookie from the > client, substituting the cookie for compressed/encrypted data should > be very quick. Nothing more than a bit of string manip. > Well that and travelling over the Internet, which is where the slow down comes in. > The actually traffic for a channel to a SQL db is going to be a little > more than a few bytes. All the handshaking and SQL server processing > of the SQL statement, the data retrieval and packaging and > transmission ... > I dunno, I'd say that should still be faster given that it's all on one side of a wide area network, but for really small pieces of data it could be slower. I'd say that for the right circumstances, putting the session data in > the cookie would be beneficial. No doubt - especially when you're starting a company and looking at a bare pocket book! -nathan
Re: [PHP] designing a post fix
You might also look at CRM applications such as Sugar CRM. --Curtis Negin Nickparsa wrote: > can u explain zimbra server 4 me? > > On Thu, Mar 17, 2011 at 9:44 PM, Curtis Maurand > wrote: >> >> Zimbra Server. >> >> Negin Nickparsa wrote: >>> :( maybe it's ticketing i don't know exactly!!!:"( >>> here are the things that i must do: >>> >>> receiving mails and return of mails >>> showing emails 2 staff >>> when a mail received it can be viewed in a moment(like ajax) >>> drafts and upload and download from mail >>> determine mails due on >>> mails that replied and can be closed >>> searching special mail or special person >>> attachments >>> forwardings >>> digital signature(I know this one is very difficult! 98% I will ignore >>> this part) >>> management of meetings and calendar in my language! >>> private messaging >>> a period time for a reply of a mail (after time if it didn’t have >>> reply then close it) >>> settings for users >>> sending sms to that user when priod time is going 2 finish >>> making priority for emergency mails >>> >>> On Thu, Mar 17, 2011 at 9:21 PM, Negin Nickparsa >>> wrote: ok! stuart plz let me think to exactly tell u what i want! because i must make sentences more clear i know i have bad english sorry! i will tell u in a moment. >>> On Thu, Mar 17, 2011 at 9:16 PM, Stuart Dallas wrote: > On Thursday, 17 March 2011 at 17:25, Negin Nickparsa wrote: > but yes i need notifications >> now we use free application named osticket but it doesn't work very >> well >> I can change my codes because i have time >> what is your suggestion for me which one can better support my site? >> MTA or another free app? > > Negin, this is starting to become a conversation I usually charge > for! > If you need help spec'ing and/or building a system I may be able to > help, but at the moment I'm unclear exactly what problem you're > trying > to solve. If you need an email solution I suggest you use Google > Apps. > If you need a ticketing system then there are lots of good options in > that area, and personally I think it would be a waste of effort to > start from scratch. If neither of those are what you're after, then > I'm > lost. > > > -Stuart > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ > > >> On Thu, Mar 17, 2011 at 8:43 PM, Negin Nickparsa >> >> wrote: >> > when a user will be logged on he/she must have the messages just >> for >> > him self yeah? then i must have a column for the mails that he >> > recieved >> > 4 example select mail1 from users where user=user1 >> > >> > i got it right? >> > >> > On Thu, Mar 17, 2011 at 8:39 PM, Negin Nickparsa >> wrote: >> > > u mean i can have localhost mail service or not? >> > > >> > > On Thu, Mar 17, 2011 at 8:36 PM, Negin Nickparsa >> wrote: >> > > > i'll give all my users user n password will they be under the >> same >> > > > domain or not? >> > > > user1 has the domain gmail n user 2 ymail >> > > > or i can have all users the same thing like dpaco.net >> > > > this is our site==>dpaco.net >> > > > i want to build another part of it with php >> > > > >> > > > On Thu, Mar 17, 2011 at 8:30 PM, Stuart Dallas >> >> wrote: >> > > > > On Thursday, 17 March 2011 at 16:56, Negin Nickparsa wrote: >> > > > > internal messaging system >> > > > > >> > > > > In that case it's simply a matter of creating a table >> structure to hold the messages and building an interface that >> will display them and allow new messages to be added, probably >> with email-based notifications. This is fairly straightforward >> stuff, you just need to think about the elements that make up >> a message, convert that list into a table structure, add some >> metadata for unread, etc. >> > > > > >> > > > > >> > > > > -Stuart >> > > > > >> > > > > -- >> > > > > Stuart Dallas >> > > > > 3ft9 Ltd >> > > > > http://3ft9.com/ >> > > > > >> > > > > >> > > > > > On Thu, Mar 17, 2011 at 8:16 PM, Stuart Dallas >> wrote: >> > > > > > > On Thursday, 17 March 2011 at 15:23, Negin Nickparsa >> wrote: >> > > > > > > i want 2 design a php web for staff members that can >> sign >> in with >> > > > > > > > their accounts n then mail 2 each other i don't know >> how >> it really >> > > > > > > > works by using a mail server i'm beginner at it! but i >> studied alot >> > > > > > > > abt it. >> > > > > > > >> > > > > > > Are you talking about interfacing with email, or an >> internal messaging system? >> > > > > > > >> > > > > > > >> > > > > > > -Stuart >> > > > > > > >> > > > > > > -- >> > > > > > > Stuart Dallas >> > > > > > > 3ft9 Ltd >> > > > > > > http://3
Re: [PHP] Acentos en tpl
Hi everyone
First, I'm so sorry to write in spanish , but when I suscribed I didn´t know
that was an english list. If I will needs again or to help I will write in
english like that. My english is not fluent, sorry again.
About this problem, this solucion doesn´t work, but my solucion was in de php
code, when I set variable with the list, encode to utf-8 and works. The
solucion was
SetVariable->('variable', utf8_encode($valor));
Thanks for your help
Lorenita Ing. Electrónica U. Bosque Ing. de Sistemas U. Bosque
Especialista en Telecomunicaciones Móviles U.Distrital
--- El vie, 3/18/11, Richard Quadling escribió:
De: Richard Quadling
Asunto: Re: [PHP] Acentos en tpl
A: "Alejandro Michelin Salomon"
Cc: "Lorena Monroy O." , php-general@lists.php.net
Fecha: viernes, 18 de marzo de 2011, 07:36 am
2011/3/18 Alejandro Michelin Salomon :
> Lorena :
>
> Yo trabajo con idioma portugués y utilizo esto en mi código :
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; xml:lang="pt-br" lang="pt-br">
>
>
> />
>
>
> ...
>
> Nunca e tenido problemas con caracteres especiales como é o ú.
> Y utilizo varios .tpl, deves fijarte en los .tpl para saber qual
> Content-Type estan utilizando.
>
> Otra cosa importante es saber si la información viene de una base de datos,
> y si esta utiliza LATIN1 como conjunto
> de caracteres o UTF-8. Para hacer las conversiones que fueren precisas
>
> Alejandro M.S.
>
> English version:
> Lorena :
>
> I work with portugues and use this in my code :
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; xml:lang="pt-br" lang="pt-br">
>
>
> />
>
>
> ...
>
> I never have problems with special characters like é or ú.
> I use some .tpl, you have to look at .tpl to know what Content-Type the file
> are using.
>
> Other important thing if to know if the information is coming from the
> database, and if is using LATIN1 CHARACTER SET
> or UTF-8. To do the conversions that are needed.
>
> Alejandro M.S.
>
>
> -Mensagem original-
> De: Lorena Monroy O. [mailto:lorenamon...@yahoo.com]
> Enviada em: quinta-feira, 17 de março de 2011 12:55
> Para: php-general@lists.php.net
> Assunto: [PHP] Acentos en tpl
>
> Hola a todos
> Tengo un formulario que tiene dos paneles (.tpl), el cual maneja variables
> que vienen de php con la funcion setVariable, pero en el panel del menu me
> carga las tildes correctamente y a la derecha me las carga como un rombo con
> interrogación. Manejo Firefox y probe cambiando la configuración de
> caracteres de UTF-8 a Occidental, pero a la izquierda se ve mal y a la
> derecha se ve bien.
> Si modifico en el codigo por ó ahi se ve bien, pero en otros combos
> no... como puedo hacer que en ese tpl se vea bien sin modificarlo desde el
> codigo.
> Gracias
>
> Lorenita Ing. Electrónica U. Bosque Ing. de Sistemas U. Bosque
> Especialista en Telecomunicaciones Móviles U.Distrital
>
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Are you able to zip the 2 templates? I'm guessing your editor is
saving one in UTF-8 and the other in the codepage format.
>From what I understand, it is better to have everything UTF-8.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
At 3:53 PM + 3/18/11, Stuart Dallas wrote: The cookies I use to replace sessions are session-based cookies and last no longer than a traditional PHP session. The key is to provide a lightweight method of ensuring that whichever server processes the request has access to the session data. -Stuart Stuart: A, I think I see. This is a means to keep a user's session current across several servers. It basically creates a "session-like" communication between servers so that a load balancer can direct traffic accordingly without losing the user's state. Is that it? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
If i am right then you have 1.44KB per request ? BR/Torsten "Stuart Dallas" schrieb: >On Friday, 18 March 2011 at 17:36, Nathan Nobbe wrote: >On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas wrote: >> > On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: >> > > > I'm curious to know what people are storing in their sessions. Is >> > > > there anything larger than a few hundred bytes that is specific and >> > > > unique to that session storage? What are the use cases for server-side >> > > > session storage because it seems like I'm missing something? >> > > >> > > I store user rights in the session but also possible to do it with a DB >> > > query every time. >> > >> > Why not store those in an encrypted cookie? Unless we're talking about >> > more than a couple of hundred bytes I see no reason to store them >> > separately server-side or to hit the DB each time. >> >> Stuart, would you not agree that sending any amount of data over the wire >> takes more time than passing it over an internal network? From my >> perspective the tradeoffs of cookies vs. server side session storage are >> application performance and cost of ownership. >> >> An application will be more responsive if less data is sent over the wire on >> each request however running a distributed session store on the server side >> can be expensive monetarily. Storing session data in cookies has it's >> merits, but I think they start to loose their benefits on large sites. The >> way I see it they can be a great way to cope with startup costs and >> server-side complexity on low traffic sites. > >Agreed, but how much traffic do you need to be getting for an extra 127 bytes >per request to make a noticeable addition to page response times or your >bandwidth bill? > >I just logged in to the main site on which I use this mechanism and checked >the headers sent by the browser. This is what got sent... > >Cookie: t=HgiivpyFIVX62BYIe4PSg4de04I92qTa1aL6yu8vQDI%3D; expires=Sat, >17-Mar-2012 17:39:36 GMT; path=/; domain=example.co.uk > >That's 126 bytes plus the LF, and that's assuming that your site sets no other >cookies. If it does then the extra weight is only 118 bytes. Obviously this >varies slightly but essentially we're talking about a very small overhead per >request. My strategy specifically aims to limit the amount of data stored in >cookies - I don't use sessions to store anything that's not absolutely >necessary. > >I would argue that an application will get more responsive with every >server-side shared resource you remove from the equation. Compare the time >taken to receive an extra 118 bytes and decrypt that data to the time taken to >make a request to a shared data storage system, bearing in mind that such a >system will get slower as the number of concurrent requests increases. > >I agree that for sites with huge amounts of traffic need to look at this type >of problem differently, but I think the level at which your perspective >changes is very high. The main site on which I use this cookie-based system >peaks at ~400 reqs/sec and pushes out just under 1.5TB of HTML per month. I've >done the calculations and the cost of maintaining a server-side session store >are huge compared to the extra bandwidth used by the cookies. > >If your app really needs to store large amounts of data in sessions (and I'm >yet to have anyone give me a solid example) then the maths will flip and >server-side storage becomes the cheaper option. > >So, in summary, you're right that the data transfer time will be lower >server-side, but there are other factors that also need to be considered. > >-Stuart > >-- >Stuart Dallas >3ft9 Ltd >http://3ft9.com/ > > > > > >-- >PHP General Mailing List (http://www.php.net/) >To unsubscribe, visit: http://www.php.net/unsub.php > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
On Friday, 18 March 2011 at 19:25, Torsten Rosenberger wrote: If i am right then you have 1.44KB per request ? > I've never done the analysis, but it's an AJAX-heavy site so that could well be the average. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ > "Stuart Dallas" schrieb: > > > On Friday, 18 March 2011 at 17:36, Nathan Nobbe wrote: > > On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas wrote: > > > > On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: > > > > > > I'm curious to know what people are storing in their sessions. Is > > > > > > there anything larger than a few hundred bytes that is specific and > > > > > > unique to that session storage? What are the use cases for > > > > > > server-side session storage because it seems like I'm missing > > > > > > something? > > > > > > > > > > I store user rights in the session but also possible to do it with a > > > > > DB query every time. > > > > > > > > Why not store those in an encrypted cookie? Unless we're talking about > > > > more than a couple of hundred bytes I see no reason to store them > > > > separately server-side or to hit the DB each time. > > > > > > Stuart, would you not agree that sending any amount of data over the wire > > > takes more time than passing it over an internal network? From my > > > perspective the tradeoffs of cookies vs. server side session storage are > > > application performance and cost of ownership. > > > > > > An application will be more responsive if less data is sent over the wire > > > on each request however running a distributed session store on the server > > > side can be expensive monetarily. Storing session data in cookies has > > > it's merits, but I think they start to loose their benefits on large > > > sites. The way I see it they can be a great way to cope with startup > > > costs and server-side complexity on low traffic sites. > > > > Agreed, but how much traffic do you need to be getting for an extra 127 > > bytes per request to make a noticeable addition to page response times or > > your bandwidth bill? > > > > I just logged in to the main site on which I use this mechanism and checked > > the headers sent by the browser. This is what got sent... > > > > Cookie: t=HgiivpyFIVX62BYIe4PSg4de04I92qTa1aL6yu8vQDI%3D; expires=Sat, > > 17-Mar-2012 17:39:36 GMT; path=/; domain=example.co.uk > > > > That's 126 bytes plus the LF, and that's assuming that your site sets no > > other cookies. If it does then the extra weight is only 118 bytes. > > Obviously this varies slightly but essentially we're talking about a very > > small overhead per request. My strategy specifically aims to limit the > > amount of data stored in cookies - I don't use sessions to store anything > > that's not absolutely necessary. > > > > I would argue that an application will get more responsive with every > > server-side shared resource you remove from the equation. Compare the time > > taken to receive an extra 118 bytes and decrypt that data to the time taken > > to make a request to a shared data storage system, bearing in mind that > > such a system will get slower as the number of concurrent requests > > increases. > > > > I agree that for sites with huge amounts of traffic need to look at this > > type of problem differently, but I think the level at which your > > perspective changes is very high. The main site on which I use this > > cookie-based system peaks at ~400 reqs/sec and pushes out just under 1.5TB > > of HTML per month. I've done the calculations and the cost of maintaining a > > server-side session store are huge compared to the extra bandwidth used by > > the cookies. > > > > If your app really needs to store large amounts of data in sessions (and > > I'm yet to have anyone give me a solid example) then the maths will flip > > and server-side storage becomes the cheaper option. > > > > So, in summary, you're right that the data transfer time will be lower > > server-side, but there are other factors that also need to be considered. > > > > -Stuart > > > > -- > > Stuart Dallas > > 3ft9 Ltd > > http://3ft9.com/ > > > > > > > > > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
On Friday, 18 March 2011 at 19:14, tedd wrote: At 3:53 PM + 3/18/11, Stuart Dallas wrote: > > The cookies I use to replace sessions are session-based cookies and > > last no longer than a traditional PHP session. The key is to provide > > a lightweight method of ensuring that whichever server processes the > > request has access to the session data. > > > > > > -Stuart > > Stuart: > > A, I think I see. > > This is a means to keep a user's session current across several > servers. It basically creates a "session-like" communication between > servers so that a load balancer can direct traffic accordingly > without losing the user's state. > > Is that it? I wouldn't call it communication, but that's the gist, yes. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Surge 2011 Conference CFP
We are excited to announce Surge 2011, the Scalability and Performance Conference, to be held in Baltimore on Sept 28-30, 2011. The event focuses on case studies that demonstrate successes (and failures) in Web applications and Internet architectures. This year, we're adding Hack Day on September 28th. The inaugural, 2010 conference (http://omniti.com/surge/2010) was a smashing success and we are currently accepting submissions for papers through April 3rd. You can find more information about topics online: http://omniti.com/surge/2011 2010 attendees compared Surge to the early days of Velocity, and our speakers received 3.5-4 out of 4 stars for quality of presentation and quality of content! Nearly 90% of first-year attendees are planning to come again in 2011. For more information about the CFP or sponsorship of the event, please contact us at surge (AT) omniti (DOT) com. -- Katherine Jeschke Marketing Director OmniTI Computer Consulting, Inc. 7070 Samuel Morse Drive, Ste.150 Columbia, MD 21046 O: 410/872-4910, 222 C: 443/643-6140 omniti.com circonus.com
Re: [PHP] PHP session replication
On Friday, 18 March 2011 at 18:06, Nathan Nobbe wrote: > CI seemed to have a problem in that it would not spill data over into > additional cookies when the size of one cookie was maxed out. One way to tell > it's time to rethink your paradigm is when you're using up the maximum number > of cookies for a given domain to propagate data between requests - been > there, lol. Again I am returned to the question of what the smeg people are storing in the session?! The only explanation I can come up with is that people are using the session as a cache, which IMO is a fundamental architectural mistake. > I'm surprised this concept was such as surprise to many of the list members, > I thought this was a well know paradigm, storing session data in cookies. Likewise, but I think it's due to the simplistic approach most books and tutorials take when teaching sessions. When you use cookies there are other issues to take into account such as security, integrity and size restrictions. It's far easier for a beginner to learn how to use the default file-based implementation of the built-in session system when learning the basics of PHP. I don't know if there are advanced books or online resources that cover using cookies, but how many people who learn PHP bother to go through learning the advanced stuff when they can do everything they need with the basics. Very few developers ever hit the scalability issues we're talking about. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
At 7:26 PM + 3/18/11, Stuart Dallas wrote: On Friday, 18 March 2011 at 19:14, tedd wrote: At 3:53 PM + 3/18/11, Stuart Dallas wrote: > The cookies I use to replace sessions are session-based cookies and > last no longer than a traditional PHP session. The key is to provide > a lightweight method of ensuring that whichever server processes the > request has access to the session data. > > > -Stuart Stuart: A, I think I see. This is a means to keep a user's session current across several servers. It basically creates a "session-like" communication between servers so that a load balancer can direct traffic accordingly without losing the user's state. Is that it? I wouldn't call it communication, but that's the gist, yes. -Stuart Are the server's sharing a common database? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
At 7:32 PM + 3/18/11, Stuart Dallas wrote: On Friday, 18 March 2011 at 18:06, Nathan Nobbe wrote: CI seemed to have a problem in that it would not spill data over into additional cookies when the size of one cookie was maxed out. One way to tell it's time to rethink your paradigm is when you're using up the maximum number of cookies for a given domain to propagate data between requests - been there, lol. Again I am returned to the question of what the smeg people are storing in the session?! The only explanation I can come up with is that people are using the session as a cache, which IMO is a fundamental architectural mistake. I'm surprised this concept was such as surprise to many of the list members, I thought this was a well know paradigm, storing session data in cookies. Likewise, but I think it's due to the simplistic approach most books and tutorials take when teaching sessions. When you use cookies there are other issues to take into account such as security, integrity and size restrictions. It's far easier for a beginner to learn how to use the default file-based implementation of the built-in session system when learning the basics of PHP. I don't know if there are advanced books or online resources that cover using cookies, but how many people who learn PHP bother to go through learning the advanced stuff when they can do everything they need with the basics. Very few developers ever hit the scalability issues we're talking about. -Stuart Stuart: In my case, that is certainly true. I use cookies to make the web sites friendly and sessions to keep things honest. I seldom think further than one server serving a single user. Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
On Friday, 18 March 2011 at 19:56, tedd wrote: At 7:26 PM + 3/18/11, Stuart Dallas wrote: > > On Friday, 18 March 2011 at 19:14, tedd wrote: > > At 3:53 PM + 3/18/11, Stuart Dallas wrote: > > > > The cookies I use to replace sessions are session-based cookies and > > > > last no longer than a traditional PHP session. The key is to provide > > > > a lightweight method of ensuring that whichever server processes the > > > > request has access to the session data. > > > > > > > > > > > > -Stuart > > > > > > Stuart: > > > > > > A, I think I see. > > > > > > This is a means to keep a user's session current across several > > > servers. It basically creates a "session-like" communication between > > > servers so that a load balancer can direct traffic accordingly > > > without losing the user's state. > > > > > > Is that it? > > > > I wouldn't call it communication, but that's the gist, yes. > > > > -Stuart > > Are the server's sharing a common database? Usually, yes, but the point is to remove the need to make a database connection unless it's absolutely necessary. If every request you're getting will hit the database anyway I see no issue with using that same database to store session data. Most of the sites I work with have a caching layer which enables the bulk of the pages (i.e. those where the content is not user-specific) to be built without accessing the database. In such situations you'll usually have some small parts of the page that are user-specific, such as the fact the user is logged in. For that you will probably want their name and/or username and their user ID. You may also want their email address to pre-fill forms, etc. I store that stuff in an encrypted cookie so I can still customise small parts of the page without hitting the DB. Hope that makes sense. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
At 8:03 PM + 3/18/11, Stuart Dallas wrote: On Friday, 18 March 2011 at 19:56, tedd wrote: At 7:26 PM + 3/18/11, Stuart Dallas wrote: > On Friday, 18 March 2011 at 19:14, tedd wrote: > At 3:53 PM + 3/18/11, Stuart Dallas wrote: > > > The cookies I use to replace sessions are session-based cookies and > > > last no longer than a traditional PHP session. The key is to provide > > > a lightweight method of ensuring that whichever server processes the > > > request has access to the session data. > > > > > > > > > -Stuart > > > > Stuart: > > > > A, I think I see. > > > > This is a means to keep a user's session current across several > > servers. It basically creates a "session-like" communication between > > servers so that a load balancer can direct traffic accordingly > > without losing the user's state. > > > > Is that it? > > I wouldn't call it communication, but that's the gist, yes. > > -Stuart Are the server's sharing a common database? Usually, yes, but the point is to remove the need to make a database connection unless it's absolutely necessary. If every request you're getting will hit the database anyway I see no issue with using that same database to store session data. Most of the sites I work with have a caching layer which enables the bulk of the pages (i.e. those where the content is not user-specific) to be built without accessing the database. In such situations you'll usually have some small parts of the page that are user-specific, such as the fact the user is logged in. For that you will probably want their name and/or username and their user ID. You may also want their email address to pre-fill forms, etc. I store that stuff in an encrypted cookie so I can still customise small parts of the page without hitting the DB. Hope that makes sense. -Stuart Stuart: When looking at: http://docstore.mik.ua/orelly/webprog/webdb/appd_03.htm I can see that sessions are tied to a db and if the servers have access to a common db, then sessions can travel between servers. When looking at: http://stut.net/2008/07/26/sessionless-sessions-2/ I see that you've tied your "session" to an encrypted cookie and of course that cookie would travel between servers because it is tied to the user's computer. In both cases, the user's activity is carried across different servers. But in your solution, I would say the data is "limited" because you are using a cookie, whereas, using a session can carry more data. On the other hand, your solution causes less burden on the server than using a database. Is that it? Cheers, tedd -- --- http://sperling.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP session replication
On Friday, 18 March 2011 at 20:18, tedd wrote: At 8:03 PM + 3/18/11, Stuart Dallas wrote: > > On Friday, 18 March 2011 at 19:56, tedd wrote: > > At 7:26 PM + 3/18/11, Stuart Dallas wrote: > > > > On Friday, 18 March 2011 at 19:14, tedd wrote: > > > > At 3:53 PM + 3/18/11, Stuart Dallas wrote: > > > > > > The cookies I use to replace sessions are session-based cookies and > > > > > > last no longer than a traditional PHP session. The key is to provide > > > > > > a lightweight method of ensuring that whichever server processes the > > > > > > request has access to the session data. > > > > > > > > > > > > > > > > > > -Stuart > > > > > > > > > > Stuart: > > > > > > > > > > A, I think I see. > > > > > > > > > > This is a means to keep a user's session current across several > > > > > servers. It basically creates a "session-like" communication between > > > > > servers so that a load balancer can direct traffic accordingly > > > > > without losing the user's state. > > > > > > > > > > Is that it? > > > > > > > > I wouldn't call it communication, but that's the gist, yes. > > > > > > > > -Stuart > > > > > > Are the server's sharing a common database? > > > > Usually, yes, but the point is to remove the need to make a database > > connection unless it's absolutely necessary. > > > > If every request you're getting will hit the database anyway I see > > no issue with using that same database to store session data. Most > > of the sites I work with have a caching layer which enables the bulk > > of the pages (i.e. those where the content is not user-specific) to > > be built without accessing the database. In such situations you'll > > usually have some small parts of the page that are user-specific, > > such as the fact the user is logged in. For that you will probably > > want their name and/or username and their user ID. You may also want > > their email address to pre-fill forms, etc. I store that stuff in an > > encrypted cookie so I can still customise small parts of the page > > without hitting the DB. > > > > Hope that makes sense. > > > > -Stuart > > Stuart: > > When looking at: > > http://docstore.mik.ua/orelly/webprog/webdb/appd_03.htm > > I can see that sessions are tied to a db and if the servers have > access to a common db, then sessions can travel between servers. I too have a MySQL implementation of sessions: http://stut.net/2008/07/20/mysql-sessions/ > When looking at: > > http://stut.net/2008/07/26/sessionless-sessions-2/ > > I see that you've tied your "session" to an encrypted cookie and of > course that cookie would travel between servers because it is tied > to the user's computer. > > In both cases, the user's activity is carried across different > servers. But in your solution, I would say the data is "limited" > because you are using a cookie, whereas, using a session can carry > more data. On the other hand, your solution causes less burden on the > server than using a database. > > Is that it? I'm not sure where the confusion is here, so let's start with the basics - I apologise if this is too basic. A cookie is data that is sent back and forth between the browser and server in HTTP headers. So it is slightly inaccurate to say that the session data "travels between servers". The session data is in the cookie which is part of the request. So it gets sent to the browser in response to a request by server A. The browser then sends that data with the next request that ends up at server B. There is no communication between the servers. With a DB-based session a cookie is usually still involved, but that cookie only stores an ID that identifies the session. For a DB-based session that would normally be the primary key in the session table. In both cases the session is "tied" to the cookie; the difference lies in where the actual session data is stored. I hope that makes it clearer. Yes, when storing the session data in a cookie there is limited space available, whereas you could say storage in a database is practically unlimited, but in return for limiting your session data and storing it in a cookie you reduce your contribution to the load on the DB. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Can´t upload files bigger than 50KB
if i'm not in mistake u can go 2 php.ini n fix it On Fri, Mar 18, 2011 at 6:24 PM, Gotzon Astondoa wrote: > I could not find the solution to the problem. > I've finally solved by using an applet that uploads the files by FTP. > In case anyone needs it, the applet I've used is > http://sourceforge.net/projects/zupload > For me it was the solution! > > 2011/3/9 Jim Lucas > >> On 3/9/2011 6:28 AM, Gotzon Astondoa wrote: >> > Hi all: >> > >> > On my website I have an Ajax form. From this form user can upload files. >> >> My guess would be that you have an HTML form. Not AJAX >> >> > Server side is a PHP script. >> > This form works properly on my development server. >> >> Is this on localhost or is it remote too? >> >> > But when I uploaded my application to the definitive server I discovered >> > that I can only upload files less than 50KB (It works perfectly with 1 to >> 20 >> > KB images). >> >> Silly question, how long does it take for these 1 to 20 KB files to upload? >> >> > These are the data from the server configuration that I believe can >> affect: >> > >> > post_max_size 8M >> > upload_max_filesize 2M >> > memory_limit 128M >> > safe_mode off >> > SELinux disabled >> > open_basedir none >> > >> > I´m now making tests with 52KB image: image.jpg >> > I discovered that the uploaded file is uploaded to /tmp. This file name >> is >> > php10tfTp. >> >> how much space is free on the partition that contains /tmp ? >> >> > But the file is not completely uploaded! So, my PHP script is not fired! >> > The original image size is 52KB and the new file size is 35KB . I >> download >> > the tmp file and rename it to php10tfTp.jpg. I can see that half frame is >> > the same as the original and the other half is gray. >> > >> > Any idea what is happening? >> > >> > Thanks in advance. >> > >> >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
