digit may be a 'X'.
AFAIK, the 10-digit ISBN numbers use the "modulus 11" algorithm, which
is also used in several other places (Danish social security numbers
for instance), and I'm sure you can adjust the weighting such that the
checkdigit is always numeric.
/Per Jessen, Zü
tory without needing
> to know the name of each file.
mv dir1/* dir2
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
his faster. I use gd to scale the image.
> Is there a faster way of doing it? Is ImageMagick better for example?
I've got a similar site - I use ImageMagick::mogrify for changing
dimensions etc. And much faster I'm sure.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.p
All,
I have a website where some of the pages require several mysql queries -
they're independent, so in principle they could easily be run in
parallel. Has anyone looked at doing that?
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit:
Colin Guthrie wrote:
> Per Jessen wrote:
>> All,
>>
>> I have a website where some of the pages require several mysql
>> queries - they're independent, so in principle they could easily be
>> run in parallel. Has anyone looked at doing that?
>
>
Colin Guthrie wrote:
> Per Jessen wrote:
>> I know how to do multiple queries - the key issue in my question was
>> how to do them concurrently (i.e. in parallel).
>
> So you want to make PHP multithreaded???
No, just the mysql queries.
/Per Jessen, Zürich
--
PHP
Edward Kay wrote:
>> Per Jessen wrote:
>> > Colin Guthrie wrote:
>> >
>> >> Per Jessen wrote:
>> >>> I know how to do multiple queries - the key issue in my question
>> >>> was how to do them concurrently (i.e. in parallel).
>
stion by the way - we are just trying to reduce
this type of batching/caching to be more real-time and/or responsive.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Richard Lynch wrote:
>
>
> On Fri, January 25, 2008 5:07 am, Colin Guthrie wrote:
>> Per Jessen wrote:
>>> I know how to do multiple queries - the key issue in my question was
>>> how
>>> to do them concurrently (i.e. in parallel).
>>
>>
;s a MASSIVE
>performance upgrade (I've cut 5 second queries down to 0.005 by using
>geo columns)
Uh, could you could elaborate a bit on that (whilst I go and do some
googling)?
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
-way box with 8Gb memory, it has multi-path SAN access - it'll
take it :-)
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
has access to shared heap storage. None of this
applies to a forked process.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Colin Guthrie wrote:
> Per Jessen wrote:
>> Colin Guthrie wrote:
>>
>>> Per Jessen wrote:
>>>> I know how to do multiple queries - the key issue in my question
>>>> was how to do them concurrently (i.e. in parallel).
>>> So you want to ma
t;>
> Try pcntl_fork() to create a child process for each query.
> Each child can make it's own MySQL connection.
Hmm, interesting idea. I wonder if that'll work under apache?
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Nathan Nobbe wrote:
> On Jan 26, 2008 3:52 AM, Nathan Rixham <[EMAIL PROTECTED]> wrote:
>
>> vote 2 for:
>> mv dir1/* dir2
>
>
> its nice, but its platform dependent.
Which surely is not that much of a drawback? (well, the OP didn't
mention it anyway).
Richard Lynch wrote:
> On Fri, January 25, 2008 3:35 am, Per Jessen wrote:
>> I have a website where some of the pages require several mysql
>> queries -
>> they're independent, so in principle they could easily be run in
>> parallel. Has anyone looked
the part
> in a variable.
Assuming you meant to grab '2b3cd5':
$matches=preg_match( '/2b3cd5/',$text,$match );
$var=$match[0];
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Richard Lynch wrote:
> On Sat, January 26, 2008 3:45 am, Per Jessen wrote:
>> Nathan Rixham wrote:
>>
>>>Back on the mysql side of things, try using geometry columns rather
>>>than numerical primary keys, with spatial indexes.. it's a MASSIVE
>>>perf
uch good as
I'm not actually fetching a lot of rows.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Richard Lynch wrote:
> On Sat, January 26, 2008 3:32 am, Per Jessen wrote:
>> In a threaded environment you often have e.g. semaphores and mutexes
>> to coordinate access to shared data. When you've forked a process,
>> you share data over IPC or similar. When you crea
Richard Lynch wrote:
> On Sat, January 26, 2008 3:22 am, Per Jessen wrote:
>> Yeah, but that's just like running off-line reports and having them
>> sent by email. It kind of ruins the idea of having the information
>> available on-line in real-time.
>
>
se apache for that sort of thing:
.htaccess:
RewriteEngine on
RewriteCond todaysphoto.jpeg !-s
RewriteRule picktodaysphoto.php
"picktodaysphoto.php" selects the photo of the day, writes it
as 'todaysphoto.jpeg', and then redirects to it.
'todaysphoto.jpeg' is then de
Per Jessen wrote:
> Well then - for people who've disabled it, there's no remote linking
> to your content. All done.
Btw, apache does a good job of dealing with remote links:
RewriteCond %{HTTP_REFERER} !^https?://jessen.ch/
RewriteRule /images/(.*) http://jessen.ch/no-remot
Robert Cummings wrote:
>
> On Tue, 2008-01-29 at 17:32 +0100, Per Jessen wrote:
>> Robert Cummings wrote:
>>
>> > The only remedy agaonst remote linking is to embed some kind of
>> > expiration in the link that accesses the document.
>>
>> Wo
ndering if the REFERER field might help you
if want to do a server-side redirect.
> Related, when target files are PDF's, images, or other than
> .php/.htm(l), does PHP provide any remedies against that
> sort of remote site linking?
Check the REFERER field.
/Per Jessen, Züric
Robert Cummings wrote:
> The only remedy agaonst remote linking is to embed some kind of
> expiration in the link that accesses the document.
Wouldn't a check of the REFERER field be enough to disable most remote
links? (I know it is easily forged.)
/Per Jessen, Zürich
--
Robert Cummings wrote:
> Referer value is completely worthless. Many people completely disable
> it-- such as myself :)
But most people probably don't - 'coz most don't know how to edit e.g.
the firefox config.
What is the purpose of disabling it?
/Per Jessen, Zürich
-
account from which you've
> come.
Hmm, interesting idea. I wonder if the sessionid isn't tied to the
IP-address even when it's part of the URL?
Still, I can't help thinking that if this is a serious problem, it would
have been dealt with long ago.
/Per Jessen, Zürich
And please don't post another 2000 lines of code. No-one is going to
read them.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
:-)
>
> while (!feof($fp)){
> echo fread($fp, 2048);
> }
And if the OP is opening the file anyway, he might as well use
readfile() instead.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Richard Lynch wrote:
> On Tue, January 29, 2008 10:32 am, Per Jessen wrote:
>> Robert Cummings wrote:
>>
>>> The only remedy agaonst remote linking is to embed some kind of
>>> expiration in the link that accesses the document.
>>
>> Wouldn't a ch
Richard Lynch wrote:
> On Tue, January 29, 2008 12:48 pm, Per Jessen wrote:
>> Robert Cummings wrote:
>>
>>> Actually, now you made me think on it... the primary reason I
>>> disable
>>> referrer logging is because it will also pass along lovely
>>&
es.. it's a MASSIVE
> performance upgrade (I've cut 5 second queries down to 0.005 by
> using geo columns)
Is this worth a try? Have others tried this?
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Richard Lynch wrote:
> On Mon, January 28, 2008 2:52 pm, Per Jessen wrote:
>> True again. However, I was commenting on your assertion that "Process
>> forking has EVERYTHING to do with thread safety", which I will stay
>> is
>> wrong. When you fork another p
Per Jessen wrote:
> No you don't. Try this example - think about running the same shell
> script twice, but concurrently. Exactly the same code (the shell
> script interpreter), but not necessarily thread-safe. Try running two
> copies of the mysql cli - same code, but als
gt; If you have even a few thousand visitors, you are likely getting at
> least a few that have no REFERER...
Like I said, I can live with that. If people are that paranoid, they
shouldn't be on the internet at all, IMHO.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
and you'll have to use a more complex scheme.
Otherwise, when you do rely on REFERER, 1) you will be shutting out
other insanely paranoid people who do not provide a REFERER and 2) you
leave your content available to individuals who forge the REFERER.
Personally I think 1) is good and 2) is ac
Robert Cummings wrote:
> Information leakage is a security issue. IMHO referer logging should
> need to be turned on, not off.
Rob, I appreciate your opinion, but like I said - when Firefox (or MSIE)
switches off REFERER by default, we can talk again.
/Per Jessen, Zürich
--
PHP G
bothered to cater to those too.
Especially when it only takes 2-3 lines of apache config to deal with
the 99.999% of my (less paranoid) users.
> Personally, I haven't munged with my referer any, but I do think it
> should be easier for users to choose whether it should be sent
> regardl
Robert Cummings wrote:
> On Thu, 2008-01-31 at 15:10 -0500, Robert Cummings wrote:
>> On Thu, 2008-01-31 at 20:49 +0100, Per Jessen wrote:
>> > Robert Cummings wrote:
>> >
>> > > Information leakage is a security issue. IMHO referer logging
>
nt
response. Quoting the HTTP spec to me was good - I'll have to be a
little wary of you in the future :-)
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
interesting if I could
> use mysql embedded server.
Alternatively, you could just run mysql locally on your desktop.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Robert Cummings wrote:
>
> On Fri, 2008-02-01 at 09:13 +0100, Per Jessen wrote:
>> Kyohere Luke wrote:
>>
>> > Has anyone tried to use this function? Does php actually support
>> > mysql embedded server or is this just a stub for future use? I'm
>>
both processes will each have a copy of those
data structures, and they can both do whatever they like to them
without interfering with each other.
Anyway, enough of this. I'm done.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
like to have the daemon write its log to its own logfile, like
> apache and mysql do.
I think "nohup 2>errorlog" will do what you're after.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
cause you can?
If you're solving a problem, and my nohup suggestion isn't sufficient,
just write your daemon in C. If it's an exercise, take a look at
proc_open().
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
I think you need to do is:
parent: fork() your child process, then do whatever.
child:use proc_open to call your program and redirect stderr.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Ron Piggott wrote:
> What is the command to reset a session variable --- essentially
> deleting all of the values it contains? Ron
>
I haven't checked, but how about unset() ?
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http
Pieter du Toit wrote:
> I am using paradigmsolutions.co.za. I read about cronjobs, but
> aparently it is only available on unix or linux hosting, is this true?
I'm sure a Windows hosting-setup will have something equivalent.
/Per Jessen, Zürich
--
PHP General Mailing List (http://
ese and hope localhost
> will work better for these mailings.
>
> Can someone give some pointers at how I may want to approach such mass
> mailings? Thanks in advance!
More bandwidth. Your 2-5Mb attachment is killing delivery performance.
/Per Jessen, Zürich
--
PHP General
ecipients at
> once but only transfer the attachment data once.
Whether you BCC or not does not affect the actual mail-server traffic.
A Bcc'ed address is only one that isn't listed in To: header.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe,
l
_could_ be transmitted only once - assuming the remote MTA can accept
all 1000 recipients in one transaction.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
he 'To:' header is a Bcc address. Your MTA
couldn't care less whether you've got 'To:' addresses or not, so the
email is transferred in the same manner with them or without.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
d to my
telephone server which uses sms_client to dial Swisscoms SMSC and send
the message. http://www.smsclient.org/
I have thought of using a more elegant solution (a provider with an
internet interface for instance), but we use SMS as an alert mechanism,
and the telephone interface is the most
Open Source, but there are times when the only way to
protect your competitive advantage is to hide your code.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
gain some performance too. Of course, once
you've done that, you might even leave PHP out of it, and just run it
as a binary.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
I don't have any clues on
> this, but that's what I would look for.
This is my favourite method. It's safe and it's easy. Authentication
could be just a shared password.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Greg Donald wrote:
> Deductive reasoning leads to two possible options:
>
> 1) Don't give the code to anyone.
> 2) Give the code to the client and accept the fact that it may get
> pirated.
Yep, that's all there is to it.
/Per Jessen, Zürich
--
PHP General Mailing
Casey wrote:
>
> Why not just translate it to C#?
Personally I'd just go for C - that way I can just distribute a binary
and be done with it. No runtime, no JVM, no mono etc.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://
s:
Get XLS file
in yourscript.php, you evaluate the parameters given and build the XSL
file as output:
header("Content-Type: application/excel");
header("Content-Disposition: attachment; filename=\"filename\"");
print
.
.
.
.
.
done.
/Per Jessen, Zürich
--
PHP
xtensions are interpreted at
runtime will depend on your browser config.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
ownload records that returned on this page only.
This is more of a caching issue - then you determine how long you want
to keep the results for, and only re-run the mysql query when the
results have gone stale.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscri
hat's a plain syntactical error, it's not related to strtotime(). Your
variable name of '18_months_ago' is not valid in PHP.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Ron Piggott wrote:
> I see I broke a rule. The variable can't start with a number. Still
> strtotime doesn't work with -18 months How would you handle this?
> Ron
Uh, it works fine here:
php5 -r '$a=strtotime("-18 months"); print strftime("%Y%m%d&qu
a local file, then do:
header("Content-Type: application/x-gzip");
Header("Content-Disposition: attached; filename=\"\"")
passthru("gzip -c ");
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
are still
> being processed and compressed - it's similar to streaming concept. I
> hope you can see what I mean.
Maybe apaches mod_deflate is what you're after? That will do in-flight
compression.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsub
the individual rows in it?
Look up mysql_fetch_assoc().
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
l-result.php
> which is what the function is using.
Yep, you're right - I read mysql_query where the OP said mysql_result.
Ignore the rest of my previous answer too.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
> ?>
I like it from a coding point of view (it's neat and elegant), but I
don't think it achieves anything else than my initial suggestion of
using exec(gzip -c).
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
ile to
> be compressed be a variable by chance?
I think in the context of this thread, the file to be compressed would
likely be a temporary file with a generated temporary name, so yes, the
filename would be held in a variable.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.ph
Stut wrote:
> Per Jessen wrote:
>> Eric Butera wrote:
>>
>>> You should never use exec & friends when there is another way around
>>> the problem. It is a security concern.
>>
>> Why is it a security concern to execute another bit of code?
&g
com";);
Yes:
mail( );
header("Location:http://domain.com";);
mail() only takes as long as it takes to drop the mail in your local
filesystem.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
_all_ session-related info in $_SESSION?
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
(please correct me if I'm wrong here, I have _no_ experience
with memcached).
> possible connection stampedes to others, their
> session info and experience is trashed (unless LVS migrates it fast
> enough)
LVS won't migrate any of your data for you. It'll shift the client
Eric Butera wrote:
> You should never use exec & friends when there is another way around
> the problem. It is a security concern.
Why is it a security concern to execute another bit of code?
I really fail to see any security concern in doing e.g.
exec('gzip -c /tmp/myinp
using execs in
> public facing code.
Why not?
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
mike wrote:
> On 2/11/08, Per Jessen <[EMAIL PROTECTED]> wrote:
>> Make sure all requests from the same client go to the same server.
>> This is often done by IP-address.
>
> isn't that an archaic piece of advice?
I hope not. I've worked with this type of
chetan rane wrote:
> HI All
>
> Can any one tell me what will be the best way to maintain session
> information on a Multi Server Architecture i.e a Web Cluster.
Make sure all requests from the same client go to the same server. This
is often done by IP-address.
/Per Jessen, Zü
he same machine"), I would
expect sendmail to be very quick, but I have no experience with the
other MTAs (sendmail itself, exim, qmail et al.)
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Stut wrote:
> Per Jessen wrote:
>> mike wrote:
>>
>>>> Check out persistency in LVS for instance:
>>>> http://www.linuxvirtualserver.org/docs/persistence.html
>>> i know persistence handling is an option in LVS, but i haven't seen
>
ould have a chance to
exacerbate the problem.
Regardless, the OP was after delivering large files compressed chunk by
chunk - I really do not see a security issue in using gzip for that,
but I still like Andre Robinets solution better.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
mike wrote:
> On 2/11/08, Per Jessen <[EMAIL PROTECTED]> wrote:
>> Because you've chosen another option - memcached presumably - which
>> is more expensive over all. (IMHO).
>
> mysql (stated above), and i already have a connection open each
> page...
Ah
wrong.
If I've got it right, virtually every access to a cached object will
require network traffic? (the exception being those cases where your
object is on your local memcached).
I've very likely overlooked something or other, but overall memcached
seems to me to be unnecessarily comp
o that
> list, especially if it means you can use it much more efficiently by
> assuming it's available.
My personal choice would be not to have my application deal directly
with caching, but that's mostly a matter of choice.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
how memcached works, hence my misguided comment about
it's lack of scalability.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
(with LVS
session persistency).
Do you write your apps specifically for use with memcached? I did think
of that, but I thought people would prefer not have their apps tied
directly to memcached. I guess it's a matter of choice.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
one server, losing people's
> session data is a crappy user experience :))
Cache layers are cheap - it's a known science after all. The key thing
(AFAICT) about memcached is that is _distributed_. You need this when
you don't have session persistency (session being the client-to
mike wrote:
> On 2/12/08, Per Jessen <[EMAIL PROTECTED]> wrote:
>
>> Cache layers are cheap - it's a known science after all. The key
>> thing
>> (AFAICT) about memcached is that is _distributed_. You need this
>> when you don't have session pers
best way is to have a local MTA (e.g. postfix), to which
mail()/sendmail can simply drop emails in the filesystem.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Brian Dunning wrote:
> Does anyone know if there's a way to send XML to MSIE7 and avoid
> having MSIE mangle the XML with CSS to display it pleasantly as HTML?
>
Isn't it enough to send it with Content-Type: application/octet-stream ?
/Per Jessen, Zürich
--
PHP General
Also, a small team has a much better of chance of getting things right
than a big team.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
ich is silly, when for
> the same price as a month or two's subscription, you could buy your
> own GSM modem and a prepaid SIM card and do it for half the price
> yourself.
Or use sms_client and only pay per individual SMS. No subscription
needed.
/Per Jessen, Zürich
--
PHP
/ which PHP library
> performs this action?
It could be apache content negotiation that does it.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Nathan Rixham wrote:
> To use url's like http://domain.com/login/ as opposed to
> http://domain.com/login.php you can take multiple approaches.
>
[big snip]
>
Seriously, this is all overkill. Apache content negotiation does it all
automagically and with minimal effort.
/P
Daniel Brown wrote:
> On Fri, Feb 22, 2008 at 10:53 AM, Per Jessen <[EMAIL PROTECTED]> wrote:
>> Nathan Rixham wrote:
>>
>> > To use url's like http://domain.com/login/ as opposed to
>> > http://domain.com/login.php you can take multiple approaches.
Nathan Rixham wrote:
> + rewrite is overkill for this, but long term it's worth implementing
> and getting used to
Completely agree. You've got to get to know url rewriting. I don't
know how you can manage without it, even if it's far from always the
right answ
7;s the algorithm
or the method.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
you don't want to hand it to your
competition free of charge. It's as easy as that.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Rick Pasotto wrote:
> What is the best or recomended proceedure for making sure that a page
> is accessed only via a secure connection?
The guaranteed way is not serving it over an insecure connection.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe,
website (www.example.com) is
accessible over http and https both. Typically you'll have separate
content, but it might be possible for a user to accidentally access
non-secure content over https which is just wasteful, or vice versa
which is clearly a security risk.
/Per Jessen, Zürich
601 - 700 of 1028 matches
Mail list logo
