Re: [PHP] PHP list as a blog
On Sunday 29 July 2007 02:18, you wrote: I'll top-post for this announcement. I think we found the winner of the Revive An Old Topic award. hup, yes its that vacation thing you posted about later ;D I just got 2278 more Congrats. On 7/28/07, Børge Holen [EMAIL PROTECTED] wrote: On Thursday 14 June 2007 00:41, Philip Thompson wrote: On Jun 13, 2007, at 1:15 PM, Richard Lynch wrote: On Wed, June 13, 2007 12:21 am, Crayon Shin Chan wrote: On Wednesday 13 June 2007 12:39, Paul Scott wrote: Our interns and students specifically. They are all dead scared of joining mailing lists in general, and find that using a web based prettier interface is much easier and friendlier. Not to mention slower, clumsier and more bandwidth hungry than a mailing list. It's time you did them a favour and show them that mailing lists are nothing to be afraid of. Do students and interns still have quotas on their email accounts?... Yes. It does depend on the university though. For our students, the default is only 50 megs - they may request more. However, these text- only emails don't really take up that much space. Cuz I *DO* remember the days when the email quotas a University would have prohibited subscribing to PHP mailing list... This is not currently the case. Surely in this day and age, the quotas aren't *that* restrictive... There seems to be some failure to comunicate (I believe the Prodigy said that)... whatever, quotas on the universities will not keep you from recieving mail... or download anything of the net. It just defines the space available to the user. The temporary space available lets you pull way more, and get a delete warning from either an automated system or an admin (at my university, wasn't it 10 days or so before forced deletion on random objects occured?... dunno). Imagine an master or phD degree getting lost because someone set up an university server with some weird download quota. This could hardly be _A_ reason for makin' this blog... the amount of mail or numbers should not be an issue. If it is so... how about them digest mails? True. ~Philip -- --- Børge http://www.arivene.net --- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- --- Børge http://www.arivene.net --- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Thursday 14 June 2007 00:41, Philip Thompson wrote: On Jun 13, 2007, at 1:15 PM, Richard Lynch wrote: On Wed, June 13, 2007 12:21 am, Crayon Shin Chan wrote: On Wednesday 13 June 2007 12:39, Paul Scott wrote: Our interns and students specifically. They are all dead scared of joining mailing lists in general, and find that using a web based prettier interface is much easier and friendlier. Not to mention slower, clumsier and more bandwidth hungry than a mailing list. It's time you did them a favour and show them that mailing lists are nothing to be afraid of. Do students and interns still have quotas on their email accounts?... Yes. It does depend on the university though. For our students, the default is only 50 megs - they may request more. However, these text- only emails don't really take up that much space. Cuz I *DO* remember the days when the email quotas a University would have prohibited subscribing to PHP mailing list... This is not currently the case. Surely in this day and age, the quotas aren't *that* restrictive... There seems to be some failure to comunicate (I believe the Prodigy said that)... whatever, quotas on the universities will not keep you from recieving mail... or download anything of the net. It just defines the space available to the user. The temporary space available lets you pull way more, and get a delete warning from either an automated system or an admin (at my university, wasn't it 10 days or so before forced deletion on random objects occured?... dunno). Imagine an master or phD degree getting lost because someone set up an university server with some weird download quota. This could hardly be _A_ reason for makin' this blog... the amount of mail or numbers should not be an issue. If it is so... how about them digest mails? True. ~Philip -- --- Børge http://www.arivene.net --- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
I'll top-post for this announcement. I think we found the winner of the Revive An Old Topic award. Congrats. On 7/28/07, Børge Holen [EMAIL PROTECTED] wrote: On Thursday 14 June 2007 00:41, Philip Thompson wrote: On Jun 13, 2007, at 1:15 PM, Richard Lynch wrote: On Wed, June 13, 2007 12:21 am, Crayon Shin Chan wrote: On Wednesday 13 June 2007 12:39, Paul Scott wrote: Our interns and students specifically. They are all dead scared of joining mailing lists in general, and find that using a web based prettier interface is much easier and friendlier. Not to mention slower, clumsier and more bandwidth hungry than a mailing list. It's time you did them a favour and show them that mailing lists are nothing to be afraid of. Do students and interns still have quotas on their email accounts?... Yes. It does depend on the university though. For our students, the default is only 50 megs - they may request more. However, these text- only emails don't really take up that much space. Cuz I *DO* remember the days when the email quotas a University would have prohibited subscribing to PHP mailing list... This is not currently the case. Surely in this day and age, the quotas aren't *that* restrictive... There seems to be some failure to comunicate (I believe the Prodigy said that)... whatever, quotas on the universities will not keep you from recieving mail... or download anything of the net. It just defines the space available to the user. The temporary space available lets you pull way more, and get a delete warning from either an automated system or an admin (at my university, wasn't it 10 days or so before forced deletion on random objects occured?... dunno). Imagine an master or phD degree getting lost because someone set up an university server with some weird download quota. This could hardly be _A_ reason for makin' this blog... the amount of mail or numbers should not be an issue. If it is so... how about them digest mails? True. ~Philip -- --- Børge http://www.arivene.net --- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, June 13, 2007 3:04 pm, Robert Cummings wrote: But you might not. It depends on what you decide to include() instead of redirecting. I guess in the included source you could code aorund not having the correct URL parameters and default to something sensible, but that still doesn't address the content/request mismatch. Bought a house, and I've been away from the list, so I'm resurrecting this only to point out... As far as I'm concerned, if it requires a login to see X, and you ask for X and aren't logged in, seeing the login page with the URL X *IS* the perfectly valid answer for what you should see. If I needed Google to index my content that requires a login, then I don't need a login because that's just a plain silly setup... Google's gonna have a bunch of pages that users can't see unless they login? Then it's not a login; It's a scam to collect a bunch of user data. :-) :-) :-) PS And I could just look at the Google User Agent and not require login for that, which anybody could forge, but so what? They'll get the same damn info by knowing what to search for in Google anyway, if I'm giving Google the content without a login. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, 2007-07-11 at 17:51 -0500, Richard Lynch wrote: On Wed, June 13, 2007 3:04 pm, Robert Cummings wrote: But you might not. It depends on what you decide to include() instead of redirecting. I guess in the included source you could code aorund not having the correct URL parameters and default to something sensible, but that still doesn't address the content/request mismatch. Bought a house, and I've been away from the list, so I'm resurrecting this only to point out... As far as I'm concerned, if it requires a login to see X, and you ask for X and aren't logged in, seeing the login page with the URL X *IS* the perfectly valid answer for what you should see. If I needed Google to index my content that requires a login, then I don't need a login because that's just a plain silly setup... Google's gonna have a bunch of pages that users can't see unless they login? Then it's not a login; It's a scam to collect a bunch of user data. :-) :-) :-) PS And I could just look at the Google User Agent and not require login for that, which anybody could forge, but so what? They'll get the same damn info by knowing what to search for in Google anyway, if I'm giving Google the content without a login. I guess what you're suggesting is a lot like using a relative URL in a redirect... it works, it saves some time, but it's not quite right ;) Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
2007. 06. 13, szerda keltezéssel 07.20-kor Paul Scott ezt írta: On Tue, 2007-06-12 at 16:02 -0500, Richard Lynch wrote: OK, downed it. Will figure out a regular expression to strip out the email addresses when I have had some coffee in the morning I have added a regex to strip out the mail addresses and replace them with a message saying that they have been removed. I will put this list back on now for a test period if that is OK? is this the link: http://196.21.45.50/fsiu/chisimba_framework/app/index.php?module=blogaction=allblogs ? (this was in your original post) because it just throws a basic 404 at me ;) greets Zoltán Németh Thanks all for the feedback, I really appreciate it! --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- 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 list as a blog
On Wed, 2007-06-13 at 12:08 +0200, Zoltán Németh wrote: is this the link: http://196.21.45.50/fsiu/chisimba_framework/app/index.php?module=blogaction=allblogs ? (this was in your original post) No, sorry, I have just updated the DNS. Try http://fsiu.uwc.ac.za/ now. --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
2007. 06. 13, szerda keltezéssel 12.11-kor Paul Scott ezt írta: On Wed, 2007-06-13 at 12:08 +0200, Zoltán Németh wrote: is this the link: http://196.21.45.50/fsiu/chisimba_framework/app/index.php?module=blogaction=allblogs ? (this was in your original post) No, sorry, I have just updated the DNS. Try http://fsiu.uwc.ac.za/ now. okay, that works. just one problem: the UTF-8 characters are screwed up (for example á and é in my name - I send my mails in UTF-8 so that cannot be the problem) greets Zoltán Németh --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 12:57 +0200, Zoltán Németh wrote: okay, that works. just one problem: the UTF-8 characters are screwed up (for example á and é in my name - I send my mails in UTF-8 so that cannot be the problem) I noticed. What we did was tack this site (which normally runs of postgres) to an older version MySQL (I think its 4.1 or so) that may or may not have the UTF-8 stuff enabled on it. I will get the mysql admins to fix it as soon as possible. --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Tue, June 12, 2007 11:39 pm, Paul Scott wrote: BTW, could I get your opinions on the blog software itself? This is running a CVS checkout of the Chisimba framework with the blog module installed. It's a blog. People type things. They show up, more or less in some kind of order. ... I don't think I'm the right guy to evaluate it, as I blog so rarely... I am currently averaging 2 posts per year, roughly, including today's rant about header(Location:): http://richardlynchblogspot.com :-) PS Regular readers of this list need not visit -- You've heard it all before from me here. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Wed, June 13, 2007 12:21 am, Crayon Shin Chan wrote: On Wednesday 13 June 2007 12:39, Paul Scott wrote: Our interns and students specifically. They are all dead scared of joining mailing lists in general, and find that using a web based prettier interface is much easier and friendlier. Not to mention slower, clumsier and more bandwidth hungry than a mailing list. It's time you did them a favour and show them that mailing lists are nothing to be afraid of. Do students and interns still have quotas on their email accounts?... Cuz I *DO* remember the days when the email quotas a University would have prohibited subscribing to PHP mailing list... Surely in this day and age, the quotas aren't *that* restrictive... -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Wed, June 13, 2007 12:29 am, Paul Scott wrote: This was done as well to give my blog code a bit of a test drive as well, I had no idea how it would perform with lots of posts too, so I will also be able to optimize queries etc as the posts fill up. Oh, we'll fill that sucker up pretty fast... :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote:
I am currently averaging 2 posts per year, roughly, including today's
rant about header(Location:):
http://richardlynchblogspot.com
I strongly disagree with your argument for the use of using require
logic instead of a redirect.
PHP responds over dog-slow Internet with 301 Redirect to login.php.
Browser interprets 301 Redirect, hopefully correctly.
This is incorrect, PHP sends a 302 status code. From the online docs:
The second special case is the Location: header. Not
only does it send this header back to the browser, but
it also returns a REDIRECT (302) status code to the
browser unless some 3xx status code has already been set.
From Wikipedia we learn:
302 Found
This is the most popular redirect code, but also an
example of industrial practice contradicting the standard.
HTTP/1.0 specification (RFC 1945) required the client to
perform a temporary redirect (the original describing
phrase was Moved Temporarily), but popular browsers
implemented it as a 303 See Other. Therefore, HTTP/1.1
added status codes 303 and 307 to disambiguate between
the two behaviors. However, majority of Web applications
and frameworks still use the 302 status code as if it
were the 303.
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI
using a GET method.
As such 302 is the best method IMHO since it is industry practiced and
supported back to HTTP/1.0.
Maybe you should consider just doing this instead:
if( !logged_in() )
{
require 'login.php';
exit;
}
I strongly disagree with this since it breaks the request/content
linking. For instance if I request:
http://l33t.pr0n.xxx/leatherAndLace.php
And you serve up a login page then I'm sure as hell not getting what I
expected. If something else should happen beyond a login request then
it's possible and VERY likely that search engines, if they can access
the content, will index the WRONG content with the URL. As such it
breaks the link/content relationship and is a bad idea.
Additionally, if there are multiple branches based on some internally
measured variable, then it is possible that parameters should be passed
to the page as would normally be done via the URL. Stuffing them into
$_GET yourself is abusive of the semantic definition of $_GET.
Additionally, users bookmarking your page will not get the same content
next time round if it is dependent on such $_GET variables.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote: I am currently averaging 2 posts per year, roughly, including today's rant about header(Location:): I was asked to write a blog, I am no blogger myself, thought it was a cool challenge to make a good one, so I took it on. Personally, I think that the blogosphere is a mix of exhibitionists and voyeurs... No offence intended, just a personal opinion. I think I need some sleep. --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 13:16 -0500, Richard Lynch wrote: Oh, we'll fill that sucker up pretty fast... :-) Thats what I am counting on! I have been on this list a while, and a couple flamewars should do the trick :) --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On 6/13/07, Richard Lynch [EMAIL PROTECTED] wrote: Oh, we'll fill that sucker up pretty fast... :-) Yeah, more or less with our off-topic useless Wednesday banter alone. I don't think I'd ever read this list if I had to get it in digest form, but a searchable blog maybe, if I'm looking for one of Robert Cummings' famous English lessons. -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 13:15 -0500, Richard Lynch wrote: Do students and interns still have quotas on their email accounts?... Students get 100MB, interns and staff too. That is storage space on the IMAP server though, if you POP it off (like I do) you can get over 1GB of mail a month (like I do) :) Cuz I *DO* remember the days when the email quotas a University would have prohibited subscribing to PHP mailing list... Pegasus mail rocked. *still* one of the best mail clients I ever used. Surely in this day and age, the quotas aren't *that* restrictive... No, not really, but the point here is that most of the students and interns that we hire to code on our framework have little to no experience switching on a PC, never mind producing decent PHP. Mailing lists, for some obscure reason, are their nemesis, so the easier I can make it for them to communicate and get over the initial barriers to FOSS development, the better. --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, June 13, 2007 12:20 am, Paul Scott wrote: On Tue, 2007-06-12 at 16:02 -0500, Richard Lynch wrote: OK, downed it. Will figure out a regular expression to strip out the email addresses when I have had some coffee in the morning I have added a regex to strip out the mail addresses and replace them with a message saying that they have been removed. I will put this list back on now for a test period if that is OK? Thanks all for the feedback, I really appreciate it! Wonderful! It is much appreciated. Now if we can just get the gname (gmane?) folks to do the same... -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, June 13, 2007 5:11 am, Paul Scott wrote: On Wed, 2007-06-13 at 12:08 +0200, Zoltán Németh wrote: is this the link: http://196.21.45.50/fsiu/chisimba_framework/app/index.php?module=blogaction=allblogs ? (this was in your original post) No, sorry, I have just updated the DNS. Try http://fsiu.uwc.ac.za/ now. Or just strip everything off the URL except for the IP address like I did :-) Actually, I tried each directory up the hierarchy in succession, as is normal for a bad URL to get to something that might be what you want. Or at least interesting, even if it's not what you want. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 15:11 -0400, Daniel Brown wrote: On 6/13/07, Richard Lynch [EMAIL PROTECTED] wrote: Oh, we'll fill that sucker up pretty fast... :-) Yeah, more or less with our off-topic useless Wednesday banter alone. I don't think I'd ever read this list if I had to get it in digest form, but a searchable blog maybe, if I'm looking for one of Robert Cummings' famous English lessons. :D -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, June 13, 2007 2:08 pm, Robert Cummings wrote: On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote: I strongly disagree with your argument for the use of using require logic instead of a redirect. PHP responds over dog-slow Internet with 301 Redirect to login.php. Browser interprets 301 Redirect, hopefully correctly. This is incorrect, PHP sends a 302 status code. From the online docs: You're right, of course, as a 301 would be a permanent redirect, and PHP doesn't know if you moved your content permanently or temporarily, so 302 (temporary) is the safe answer... The second special case is the Location: header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless some 3xx status code has already been set. You're still sending the response to the browser, then the browser has to interpret it, then the browser has to request the new URL, chewing up another HTTP connection resource, and bogging down your server, before PHP can be invoked a second time, to do an include 'login.php'... Or you could just include 'login.php' in the first place, and SKIP ALL THAT CRAP. From Wikipedia we learn: 302 Found This is the most popular redirect code, but also an example of industrial practice contradicting the standard. HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was Moved Temporarily), but popular browsers implemented it as a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to disambiguate between the two behaviors. However, majority of Web applications and frameworks still use the 302 status code as if it were the 303. IE is the one that chose to mis-interpret a POST with a 302 response with an incomplete URI as a 303. *HOW* MS managed to code that badly is beyond my ken, but there it is. I alluded to this in my blog. As such 302 is the best method IMHO since it is industry practiced and supported back to HTTP/1.0. I don't really care which 30x code you use -- You're STILL bouncing the user like a white ferret [*] instead of just doing the 'include' you're going to need to do in the end. I strongly disagree with this since it breaks the request/content linking. For instance if I request: http://l33t.pr0n.xxx/leatherAndLace.php And you serve up a login page then I'm sure as hell not getting what I expected. If something else should happen beyond a login request then it's possible and VERY likely that search engines, if they can access the content, will index the WRONG content with the URL. As such it breaks the link/content relationship and is a bad idea. If you're silly enough to hard-code the response now of a dynamic page as if it were the one and only response ever, then you've got much bigger problems than a silly login form... Additionally, if there are multiple branches based on some internally measured variable, then it is possible that parameters should be passed to the page as would normally be done via the URL. Stuffing them into $_GET yourself is abusive of the semantic definition of $_GET. Additionally, users bookmarking your page will not get the same content next time round if it is dependent on such $_GET variables. I have NO IDEA what heck you are talking about with stuffing values into $_GET variables, unless, of course, you refer to people who do: header(Location: example.com?foo=$_GET[foo]); and expect it to work... Whereas I'm suggesting that you already HAVE your $_GET data, and you already KNOW what content to server up for *THIS* request, and you should just serve up the content you're supposed to serve up and be done with it. PS I also usually serve up a nice full page with a login form in the middle rather than just the login form, so, really, the search engine is only going to get exactly what I wanted it to get in the first place. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
Robert Cummings wrote:
On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote:
PHP responds over dog-slow Internet with 301 Redirect to login.php.
Browser interprets 301 Redirect, hopefully correctly.
This is incorrect, PHP sends a 302 status code. From the online docs:
The second special case is the Location: header. Not
only does it send this header back to the browser, but
it also returns a REDIRECT (302) status code to the
browser unless some 3xx status code has already been set.
Indeed, this is correct.
From Wikipedia we learn:
302 Found
This is the most popular redirect code, but also an
example of industrial practice contradicting the standard.
HTTP/1.0 specification (RFC 1945) required the client to
perform a temporary redirect (the original describing
phrase was Moved Temporarily), but popular browsers
implemented it as a 303 See Other. Therefore, HTTP/1.1
added status codes 303 and 307 to disambiguate between
the two behaviors. However, majority of Web applications
and frameworks still use the 302 status code as if it
were the 303.
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI
using a GET method.
As such 302 is the best method IMHO since it is industry practiced and
supported back to HTTP/1.0.
Not entirely. 301 and 302 responses are both equally valid but mean
subtly different things.
A 302 is a temporary redirect. Essentially it tells the client to load a
different resource but nothing more than that.
A 301 is a permanent redirect. This tells the client to load a different
resource, and that any time that original URL is requested it will be
redirected. Essentially this means bookmarks and indexes should be
modified to point to the new URL.
Maybe you should consider just doing this instead:
if( !logged_in() )
{
require 'login.php';
exit;
}
I strongly disagree with this since it breaks the request/content
linking. For instance if I request:
http://l33t.pr0n.xxx/leatherAndLace.php
And you serve up a login page then I'm sure as hell not getting what I
expected. If something else should happen beyond a login request then
it's possible and VERY likely that search engines, if they can access
the content, will index the WRONG content with the URL. As such it
breaks the link/content relationship and is a bad idea.
Completely agree with this, but there are lots of reasons to include
files rather than bouncing off the client with a new URL, login
requirements is just one example where a redirect would be preferred.
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On 6/13/07, Richard Lynch [EMAIL PROTECTED] wrote: On Wed, June 13, 2007 12:20 am, Paul Scott wrote: On Tue, 2007-06-12 at 16:02 -0500, Richard Lynch wrote: OK, downed it. Will figure out a regular expression to strip out the email addresses when I have had some coffee in the morning I have added a regex to strip out the mail addresses and replace them with a message saying that they have been removed. I will put this list back on now for a test period if that is OK? Thanks all for the feedback, I really appreciate it! Wonderful! It is much appreciated. Now if we can just get the gname (gmane?) folks to do the same... -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Think they ever check their own archives to see what's being said about them? Taking sidebar for a moment, I wonder how many places don't sanitize the text from emails piped through their scripts. How much do you want to bet that, by sending text to a mailing list, you could arbitrarily execute code on some of the lesser archiving sites? Maybe we should dedicate a thread to that instead of YACAPTCHA discussion. -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 20:37 +0100, Stut wrote:
Robert Cummings wrote:
On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote:
PHP responds over dog-slow Internet with 301 Redirect to login.php.
Browser interprets 301 Redirect, hopefully correctly.
This is incorrect, PHP sends a 302 status code. From the online docs:
The second special case is the Location: header. Not
only does it send this header back to the browser, but
it also returns a REDIRECT (302) status code to the
browser unless some 3xx status code has already been set.
Indeed, this is correct.
From Wikipedia we learn:
302 Found
This is the most popular redirect code, but also an
example of industrial practice contradicting the standard.
HTTP/1.0 specification (RFC 1945) required the client to
perform a temporary redirect (the original describing
phrase was Moved Temporarily), but popular browsers
implemented it as a 303 See Other. Therefore, HTTP/1.1
added status codes 303 and 307 to disambiguate between
the two behaviors. However, majority of Web applications
and frameworks still use the 302 status code as if it
were the 303.
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI
using a GET method.
As such 302 is the best method IMHO since it is industry practiced and
supported back to HTTP/1.0.
Not entirely. 301 and 302 responses are both equally valid but mean
subtly different things.
A 302 is a temporary redirect. Essentially it tells the client to load a
different resource but nothing more than that.
A 301 is a permanent redirect. This tells the client to load a different
resource, and that any time that original URL is requested it will be
redirected. Essentially this means bookmarks and indexes should be
modified to point to the new URL.
Yep, I understand that, but the usage example Richard mentioned is
primarily where developers redirect to an alternate location given that
they didn't set the response code themself and relied on PHP's default.
Maybe you should consider just doing this instead:
if( !logged_in() )
{
require 'login.php';
exit;
}
I strongly disagree with this since it breaks the request/content
linking. For instance if I request:
http://l33t.pr0n.xxx/leatherAndLace.php
And you serve up a login page then I'm sure as hell not getting what I
expected. If something else should happen beyond a login request then
it's possible and VERY likely that search engines, if they can access
the content, will index the WRONG content with the URL. As such it
breaks the link/content relationship and is a bad idea.
Completely agree with this, but there are lots of reasons to include
files rather than bouncing off the client with a new URL, login
requirements is just one example where a redirect would be preferred.
IMHO an include is preferrable if the content being displayed makes
sense in the context of the URL requested.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 14:36 -0500, Richard Lynch wrote: On Wed, June 13, 2007 2:08 pm, Robert Cummings wrote: On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote: I strongly disagree with your argument for the use of using require logic instead of a redirect. PHP responds over dog-slow Internet with 301 Redirect to login.php. Browser interprets 301 Redirect, hopefully correctly. This is incorrect, PHP sends a 302 status code. From the online docs: You're right, of course, as a 301 would be a permanent redirect, and PHP doesn't know if you moved your content permanently or temporarily, so 302 (temporary) is the safe answer... Or it's the statistically safe bet since it's more likely your content didn't move and that you're just doing a temporary redirect. The second special case is the Location: header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless some 3xx status code has already been set. You're still sending the response to the browser, then the browser has to interpret it, then the browser has to request the new URL, chewing up another HTTP connection resource, and bogging down your server, before PHP can be invoked a second time, to do an include 'login.php'... Or you could just include 'login.php' in the first place, and SKIP ALL THAT CRAP. The extra request is not a good excuse for breaking the semantic linking of the web. I didn't request login.php, I requested leatherAndLace.php and so I want leather and lace or you better tell me I'm on the wrong page. It's like walking into a bar, requesting a pint of Guinness and the bartender say, sorry I haven't checked your ID, but to save myself a trip I'll just give you a Shirley Temple... you sould be fine with that right? HELL NO!! I want my Guinness! :) From Wikipedia we learn: 302 Found This is the most popular redirect code, but also an example of industrial practice contradicting the standard. HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was Moved Temporarily), but popular browsers implemented it as a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to disambiguate between the two behaviors. However, majority of Web applications and frameworks still use the 302 status code as if it were the 303. IE is the one that chose to mis-interpret a POST with a 302 response with an incomplete URI as a 303. 303 didn't exist in HTTP/1.0, you have to do something. 302 was a close enough match in HTTP/1.0 and HTTP/1.1 that it became the industry standard regardless of what Microsoft did. *HOW* MS managed to code that badly is beyond my ken, but there it is. I alluded to this in my blog. As such 302 is the best method IMHO since it is industry practiced and supported back to HTTP/1.0. I don't really care which 30x code you use -- You're STILL bouncing the user like a white ferret [*] instead of just doing the 'include' you're going to need to do in the end. I'm bouncing them around because I'm the incorrect source for the information they a requesting. There is a proper chain of command to be followed. First they must log in. If a user just registered on my website via http://foo.fee.com/register.php and they complete the registration and I just go ahead and include news.php how is that semantically valid? No, I redirect them to news.php so they can bookmark it if it happens to interest them. I strongly disagree with this since it breaks the request/content linking. For instance if I request: http://l33t.pr0n.xxx/leatherAndLace.php And you serve up a login page then I'm sure as hell not getting what I expected. If something else should happen beyond a login request then it's possible and VERY likely that search engines, if they can access the content, will index the WRONG content with the URL. As such it breaks the link/content relationship and is a bad idea. If you're silly enough to hard-code the response now of a dynamic page as if it were the one and only response ever, then you've got much bigger problems than a silly login form... If you're short-sighted enough to serve up mismatched content with the actual request then you deserve the soup of Bookmarked links that point to incorrect pages that your users create. Additionally, if there are multiple branches based on some internally measured variable, then it is possible that parameters should be passed to the page as would normally be done via the URL. Stuffing them into $_GET yourself is abusive of the semantic definition of $_GET. Additionally, users bookmarking your page will not get the same content next time round if it is dependent on such $_GET variables. I have NO IDEA what heck you are talking about with stuffing values
Re: [PHP] PHP list as a blog
On Jun 13, 2007, at 1:15 PM, Richard Lynch wrote: On Wed, June 13, 2007 12:21 am, Crayon Shin Chan wrote: On Wednesday 13 June 2007 12:39, Paul Scott wrote: Our interns and students specifically. They are all dead scared of joining mailing lists in general, and find that using a web based prettier interface is much easier and friendlier. Not to mention slower, clumsier and more bandwidth hungry than a mailing list. It's time you did them a favour and show them that mailing lists are nothing to be afraid of. Do students and interns still have quotas on their email accounts?... Yes. It does depend on the university though. For our students, the default is only 50 megs - they may request more. However, these text- only emails don't really take up that much space. Cuz I *DO* remember the days when the email quotas a University would have prohibited subscribing to PHP mailing list... This is not currently the case. Surely in this day and age, the quotas aren't *that* restrictive... True. ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote: On Tue, June 12, 2007 11:39 pm, Paul Scott wrote: It's a blog. People type things. Not quite anymore... I have added our set of filters to the output now, so that you can add in bbcode tags as well as a number of other things, like youtube videos, google maps, google videos timelines, mindmaps (freemind), personal data etc etc. --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP list as a blog
I have set up our new Chisimba blog system (GPL, http://avoir.uwc.ac.za) to blog all of the posts to this list. Please check it out at http://196.21.45.50/fsiu/chisimba_framework/app/index.php?module=blogaction=allblogs and let me know what you think! Thanks --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Tue, June 12, 2007 1:52 pm, Paul Scott wrote: I have set up our new Chisimba blog system (GPL, http://avoir.uwc.ac.za) to blog all of the posts to this list. Please check it out at http://196.21.45.50/fsiu/chisimba_framework/app/index.php?module=blogaction=allblogs and let me know what you think! I think you should take it DOWN until you can obfuscate the emails. I don't really need yet another place for my email address to be spam-harvested, thank you very much. :-) :-) :-) PS And you've only got 16 Tidy HTML warnings to get rid of before it's valid HTML, so you might as well do that too. :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
[snip] I think you should take it DOWN until you can obfuscate the emails. I don't really need yet another place for my email address to be spam-harvested, thank you very much. :-) :-) :-) PS And you've only got 16 Tidy HTML warnings to get rid of before it's valid HTML, so you might as well do that too. :-) [/snip] + 10*12^23, I don't want to be that famous. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Tue, 2007-06-12 at 14:48 -0500, Richard Lynch wrote: I think you should take it DOWN until you can obfuscate the emails. I am working on it at the moment. It seems that it only shows some people's addresses - presumably those that have the reply to thing set? --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Tue, 2007-06-12 at 14:56 -0500, Jay Blanchard wrote: + 10*12^23, I don't want to be that famous. OK, downed it. Will figure out a regular expression to strip out the email addresses when I have had some coffee in the morning --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Tue, June 12, 2007 3:10 pm, Paul Scott wrote: On Tue, 2007-06-12 at 14:56 -0500, Jay Blanchard wrote: + 10*12^23, I don't want to be that famous. OK, downed it. Will figure out a regular expression to strip out the email addresses when I have had some coffee in the morning I'm not sure we need yet another archive of the list, though I suppose having it on a blog with the RSS and whatnot all built-in is kinda nifty, possibly, for some users somewhere. I got no idea why some emails appear and others don't. Sorry. Hopefully comparing email headers to output will clarify that. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Tue, 2007-06-12 at 16:02 -0500, Richard Lynch wrote: I'm not sure we need yet another archive of the list, though I suppose having it on a blog with the RSS and whatnot all built-in is kinda nifty, possibly, for some users somewhere. Our interns and students specifically. They are all dead scared of joining mailing lists in general, and find that using a web based prettier interface is much easier and friendlier. They will also now be able to at least read what is going on through the RSS feeds etc as well as have an easily searchable archive of various lists (Planning on aggregating a bunch of lists including PHP, PEAR, (which we use in our daily work building Chisimba and the Chisimba Framework) as well as some decent linux users groups etc. I got no idea why some emails appear and others don't. Sorry. I am pretty sure that it is only people that have a reply-to address specified in their mail client. Not to worry though, I will have a regex smashed out in no time to strip out the RFC formatted email addresses... Hopefully comparing email headers to output will clarify that. Not sure what you mean there, but, rest assured, I will have it fixed up in no time. BTW, could I get your opinions on the blog software itself? This is running a CVS checkout of the Chisimba framework with the blog module installed. (Oh and I will get to the W3C compliance ASAP as well - I was leaving it until I had put in all of the features so as to fix it once...) --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP list as a blog
On Tue, 2007-06-12 at 16:02 -0500, Richard Lynch wrote: OK, downed it. Will figure out a regular expression to strip out the email addresses when I have had some coffee in the morning I have added a regex to strip out the mail addresses and replace them with a message saying that they have been removed. I will put this list back on now for a test period if that is OK? Thanks all for the feedback, I really appreciate it! --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Wednesday 13 June 2007 12:39, Paul Scott wrote: Our interns and students specifically. They are all dead scared of joining mailing lists in general, and find that using a web based prettier interface is much easier and friendlier. Not to mention slower, clumsier and more bandwidth hungry than a mailing list. It's time you did them a favour and show them that mailing lists are nothing to be afraid of. -- Crayon -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP list as a blog
On Wed, 2007-06-13 at 13:21 +0800, Crayon Shin Chan wrote: Not to mention slower, clumsier and more bandwidth hungry than a mailing list. It's time you did them a favour and show them that mailing lists are nothing to be afraid of. Absolutely! I couldn't agree more! It is really very difficult to change mindsets, but if you show people slowly that the world is not so bad, they tend to work on it better. In Africa, we have massive bandwidth problems, but in order to address some of these issues, we have to get people communicating via the path of least resistance first, hence the need for these types of systems. This was done as well to give my blog code a bit of a test drive as well, I had no idea how it would perform with lots of posts too, so I will also be able to optimize queries etc as the posts fill up. --Paul All Email originating from UWC is covered by disclaimer http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
