php-general Digest 2 Jul 2008 14:04:44 -0000 Issue 5546
Topics (messages 276206 through 276223):
Re: V4 Vs V5 Issue
276206 by: Neil
276212 by: Neil
PHP-CLI and the "less" command (kubuntu)
276207 by: Mattias Thorslund
276218 by: Stut
276223 by: Mattias Thorslund
Re: Strategy to protect images
276208 by: Bastien Koert
276213 by: Børge Holen
Re: CURL de-bugging: So why am I not getting the results page on the target
site?
276209 by: Chris
276210 by: Chris
276211 by: Andrew Ballard
276221 by: ioannes
Re: Splitting up long URLs
276214 by: Jason Norwood-Young
276215 by: Jason Norwood-Young
Session variables disappear (some of them only)
276216 by: karma
Re: [SPAM] [PHP] FIFO files on PHP?
276217 by: Chris Scott
URL Rewrite
276219 by: Subhranil
276220 by: Per Jessen
276222 by: Bastien Koert
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Thanks Jim
Two things come to mind.
1) Is their any PHP inside you javascript file that needs to be
parsed? And if so, is the new V5 install configured in such a way
that it parses/processes javascript files? where the old install was
processing javascript files. This would be a configuration issue
from the actual web server POV. i.e. Apache, lighttpd,
etc... Once reconfigured, make sure you restart your web server.
Yes there is PHP inside the javascript that is being passed. As an
exorcise I was just looking at deleting it all out of the code and
seeing what happens, however it is everywhere.
The Webserver with the V5 PHP is Apache 2.2.4, but I can not really
see where I would make the changes you are suggesting.
The older server with V4 is Apache 1.34.4
2) Is your code using short tags in php? This allows the programmer
to use <? instead of <?php . In this case you might want to
enable short tags in the new version of PHP. I think php 5 comes
with short tags disabled and version 4 had it enabled by
default. This setting would be found in your php.ini file on the
server. If you need to change the setting, make sure you restart
your httpd server before testing.
Short tags is enabled and working.... most of the application is short tagged.
Cheers
Neil
Just a couple of thoughts
--
Jim Lucas
"Some men are born to greatness, some achieve greatness,
and some have greatness thrust upon them."
Twelfth Night, Act II, Scene V
by William Shakespeare
--- End Message ---
--- Begin Message ---
Thanks Jim
Will add some more to this.
The PHP that is parsed inside this file and the JS is I think working
correctly because the values are populated in the JavaScript output
that is being displayed in the IE source viewer.
For instance there is a stack of variable that are defined up front,
these get information from PHP, these have the same information as
the V4 server and I can therefore only presume the correct information.
Cheers N
Two things come to mind.
1) Is their any PHP inside you javascript file that needs to be
parsed? And if so, is the new V5 install configured in such a way
that it parses/processes javascript files? where the old install was
processing javascript files. This would be a configuration issue
from the actual web server POV. i.e. Apache, lighttpd,
etc... Once reconfigured, make sure you restart your web server.
Yes there is PHP inside the javascript that is being passed. As an
exorcise I was just looking at deleting it all out of the code and
seeing what happens, however it is everywhere.
The Webserver with the V5 PHP is Apache 2.2.4, but I can not really
see where I would make the changes you are suggesting.
The older server with V4 is Apache 1.34.4
2) Is your code using short tags in php? This allows the programmer
to use <? instead of <?php . In this case you might want to
enable short tags in the new version of PHP. I think php 5 comes
with short tags disabled and version 4 had it enabled by
default. This setting would be found in your php.ini file on the
server. If you need to change the setting, make sure you restart
your httpd server before testing.
Short tags is enabled and working.... most of the application is short tagged.
Cheers
Neil
Just a couple of thoughts
--
Jim Lucas
"Some men are born to greatness, some achieve greatness,
and some have greatness thrust upon them."
Twelfth Night, Act II, Scene V
by William Shakespeare
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Hi everyone,
I have a CLI application that produces lots of output to the terminal,
so I like to send the output along to the "less" command. This has
always worked very nicely. Moving to the top or bottom of the output
used to require just hitting the "home" or "end" key, and the up and
down arrows as well as page up and page down worked nicely.
After upgrading to Hardy on Kubuntu, the behavior changed. Now, it seems
to preempt the navigation and instead print ugly codes for each press on
a "navigational key" (one of those mentioned above), such as ^[OF. When
I press "enter", the desired scroll is executed. Scrolling up and down
is one thing, but it's particularly a pain when trying to search through
the output, as it would no longer look up previous search arguments.
I thought at first it's a problem with Konsole, my terminal program, or
with "less" itself. But I've now tried in different terminal programs,
and reading output other than output from PHP, and the ONLY time it
happens is when I pipe output from PHP to "less". I have added a small
test script that exhibits the problem on my system. It may work well the
first time, but when repeating the same command a second time, the
"weird" behavior starts.
It could very well be some kind of problem with "less", but since I can
only reproduce the problem with output from PHP CLI, I thought it's
worth asking here.
Did something about PHP CLI output change lately?
My test script:
<?php
$count = 0;
while ($count < 100){
echo "This is line number $count\n";
$count++;
}
?>
Execute like so:
$ php test.php | less
First time might work without problem, but subsequent times not.
Thanks for any feedback and observations.
Mattias
--- End Message ---
--- Begin Message ---
On 2 Jul 2008, at 02:58, Mattias Thorslund wrote:
Hi everyone,
I have a CLI application that produces lots of output to the
terminal, so I like to send the output along to the "less" command.
This has always worked very nicely. Moving to the top or bottom of
the output used to require just hitting the "home" or "end" key, and
the up and down arrows as well as page up and page down worked nicely.
After upgrading to Hardy on Kubuntu, the behavior changed. Now, it
seems to preempt the navigation and instead print ugly codes for
each press on a "navigational key" (one of those mentioned above),
such as ^[OF. When I press "enter", the desired scroll is executed.
Scrolling up and down is one thing, but it's particularly a pain
when trying to search through the output, as it would no longer look
up previous search arguments.
I thought at first it's a problem with Konsole, my terminal program,
or with "less" itself. But I've now tried in different terminal
programs, and reading output other than output from PHP, and the
ONLY time it happens is when I pipe output from PHP to "less". I
have added a small test script that exhibits the problem on my
system. It may work well the first time, but when repeating the same
command a second time, the "weird" behavior starts.
It could very well be some kind of problem with "less", but since I
can only reproduce the problem with output from PHP CLI, I thought
it's worth asking here.
Did something about PHP CLI output change lately?
This has nothing to do with PHP. The keystrokes are processed by less
so your problem lies there or more likely with the terminal emulation
you're using. Please try a more relevant list.
-Stut
--
http://stut.net/
--- End Message ---
--- Begin Message ---
Stut wrote:
On 2 Jul 2008, at 02:58, Mattias Thorslund wrote:
Hi everyone,
I have a CLI application that produces lots of output to the
terminal, so I like to send the output along to the "less" command.
This has always worked very nicely. Moving to the top or bottom of
the output used to require just hitting the "home" or "end" key, and
the up and down arrows as well as page up and page down worked nicely.
After upgrading to Hardy on Kubuntu, the behavior changed. Now, it
seems to preempt the navigation and instead print ugly codes for each
press on a "navigational key" (one of those mentioned above), such as
^[OF. When I press "enter", the desired scroll is executed. Scrolling
up and down is one thing, but it's particularly a pain when trying to
search through the output, as it would no longer look up previous
search arguments.
I thought at first it's a problem with Konsole, my terminal program,
or with "less" itself. But I've now tried in different terminal
programs, and reading output other than output from PHP, and the ONLY
time it happens is when I pipe output from PHP to "less". I have
added a small test script that exhibits the problem on my system. It
may work well the first time, but when repeating the same command a
second time, the "weird" behavior starts.
It could very well be some kind of problem with "less", but since I
can only reproduce the problem with output from PHP CLI, I thought
it's worth asking here.
Did something about PHP CLI output change lately?
This has nothing to do with PHP. The keystrokes are processed by less
so your problem lies there or more likely with the terminal emulation
you're using. Please try a more relevant list.
-Stut
I agree the keystrokes are processed by less. This is probably more a
problem with "less". Yes I will ask on other lists as well.
I thought it was irrelevant to PHP until I tried to provoke the same
behavior by reading large files or other console input. Nope, only PHP
output does it, so I figured someone here might have encountered this
behavior too.
Mattias
Maybe you didn't
--- End Message ---
--- Begin Message ---
On Tue, Jul 1, 2008 at 2:16 PM, Stefano Esposito <[EMAIL PROTECTED]> wrote:
> On Tue, 01 Jul 2008 19:59:20 +0200
> Børge Holen <[EMAIL PROTECTED]> wrote:
>
> > On Tuesday 01 July 2008 13:34:28 Nitsan Bin-Nun wrote:
> > > Umm have you ever thought about watermark-ing it? (In case its not
> > > a part of your website or something..)
> >
> > heh, this dude got way to much time on his hands... ;D
> >
>
> This dude has commitments, and watermark is not an option.
>
>
> --
> Email.it, the professional e-mail, gratis per te: http://www.email.it/f
>
> Sponsor:
> Vasco è tornato! Sul tuo cellulare Il mondo che vorrei
> Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?midw49&d1-7
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
since the image is sent to the client browser, anyone with enough brains to
look in the cache will be able to access the image. What about setting the
image to show only inside a flash viewer with ming?
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
On Wednesday 02 July 2008 04:39:57 Bastien Koert wrote:
> On Tue, Jul 1, 2008 at 2:16 PM, Stefano Esposito <[EMAIL PROTECTED]> wrote:
> > On Tue, 01 Jul 2008 19:59:20 +0200
> >
> > Børge Holen <[EMAIL PROTECTED]> wrote:
> > > On Tuesday 01 July 2008 13:34:28 Nitsan Bin-Nun wrote:
> > > > Umm have you ever thought about watermark-ing it? (In case its not
> > > > a part of your website or something..)
> > >
> > > heh, this dude got way to much time on his hands... ;D
> >
> > This dude has commitments, and watermark is not an option.
> >
> >
> > --
> > Email.it, the professional e-mail, gratis per te: http://www.email.it/f
> >
> > Sponsor:
> > Vasco è tornato! Sul tuo cellulare Il mondo che vorrei
> > Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?midw49&d1-7
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> since the image is sent to the client browser, anyone with enough brains to
> look in the cache will be able to access the image. What about setting the
> image to show only inside a flash viewer with ming?
I hope flash dies out in a silent bang. However, why he is going throught
every nonsecure option trying to keep some images safe instead of either
don't put them out at all or using flash as the easy way out is beyond me
--
---
Børge Holen
http://www.arivene.net
--- End Message ---
--- Begin Message ---
ioannes wrote:
> I didn't get any brave response on this, but given the other thread on
> 'encription' I was wondering could anyone decrypt the __VIEWSTATE string
> at the end of this message. It is part of the input page whose results
> page I am trying to retrieve back onto my server for further php work.
> I replicated the source from that input page onto a page on my server,
> and when I click the submit button it correctly goes to the target
> results page, on the other site though, however it did not work without
> the whole of the string below. The experiment proved though that
> without the __VIEWSTATE the results page will not return. So I am just
> wondering, as I have not been able to repeat this using curl, what the
> **** is included in that string. There's a challenge for anyone with
> whatever resources it takes.
echo base64_decode($view_state_string);
viewstate in asp.net is like sessions in php (I believe, I could be
completely wrong :P).
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
Chris wrote:
> ioannes wrote:
>> I didn't get any brave response on this, but given the other thread on
>> 'encription' I was wondering could anyone decrypt the __VIEWSTATE string
>> at the end of this message. It is part of the input page whose results
>> page I am trying to retrieve back onto my server for further php work.
>> I replicated the source from that input page onto a page on my server,
>> and when I click the submit button it correctly goes to the target
>> results page, on the other site though, however it did not work without
>> the whole of the string below. The experiment proved though that
>> without the __VIEWSTATE the results page will not return. So I am just
>> wondering, as I have not been able to repeat this using curl, what the
>> **** is included in that string. There's a challenge for anyone with
>> whatever resources it takes.
>
> echo base64_decode($view_state_string);
or maybe
print_r(base64_decode($view_state_string));
I don't know if it will return a string or an array or something else.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
On Tue, Jul 1, 2008 at 5:23 PM, ioannes <[EMAIL PROTECTED]> wrote:
> I didn't get any brave response on this, but given the other thread on
> 'encription' I was wondering could anyone decrypt the __VIEWSTATE string at
> the end of this message. It is part of the input page whose results page I
> am trying to retrieve back onto my server for further php work. I
> replicated the source from that input page onto a page on my server, and
> when I click the submit button it correctly goes to the target results page,
> on the other site though, however it did not work without the whole of the
> string below. The experiment proved though that without the __VIEWSTATE the
> results page will not return. So I am just wondering, as I have not been
> able to repeat this using curl, what the **** is included in that string.
> There's a challenge for anyone with whatever resources it takes.
>
> John
>
>
> ioannes wrote:
>>
>> For those that like CURL and calendars.
>> ...........................................
>>
>> VIEWSTATE
>>
>> curl_setopt($ch,
>> CURLOPT_POSTFIELDS,"__VIEWSTATE=/wEPDwUKMTMyMjM3NTUzNw9kFgZmDxYCHgRUZXh0BYcMPHRhYmxlIGFsaWduPSJjZW50ZXIiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgYm9yZGVyPSIwIj48dHI+PHRkPg0KPHVsIGlkPSJza2lwIj4NCiA8bGk+PGEgaHJlZj0iI21haW4iPlNraXAgdG8gbWFpbiBjb250ZW50PC9hPjwvbGk+DQo8L3VsPg0KPGRpdiBpZD0id3JhcHBlciIgY2xhc3M9ImNsZWFyIj4NCiA8ZGl2IGlkPSJoZWFkZXIiPg0KICAgICAgICAgICAgPGgxPg0KICAgICAgICAgICAgICAgIDxhIGhyZWY9Imh0dHA6Ly93d3cuZG9scGhpbnNxdWFyZS5jby51ay9ob3VzZS8iIHRpdGxlPSJEb2xwaGluIEhvdXNlIGhvbWUgcGFnZSI+RG9scGhpbg0KICAgICAgICAgICAgICAgICAgICBIb3VzZTwvYT48L2gxPg0KICAgICAgICAgICAgPGRpdiBpZD0ibmF2aWdhdGlvbiI+DQogICAgICAgICAgICAgICAgPHVsIGlkPSJuYXZfbWFpbiI+DQogICAgICAgICAgICAgICAgICAgIDxsaSBjbGFzcz0iYWJvdXQiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZG9scGhpbnNxdWFyZS5jby51ay9ob3VzZS9hYm91dC8iIHRpdGxlPSJBYm91dCBEb2xwaGluIEhvdXNlIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIEFib3V0IHVzPC9hPiA8L2xpPg0KICAgICAgICAgICAgICAgICAgICA8bGkgY2xhc3M9ImFyZWEiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZG9scGhpbnNxdWFyZS5jby51ay9ob3VzZS90aGVhcmVhLyIgdGl0bGU9IlRoZSBhcmVhIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBhcmVhPC9hPiA8L2xpPg0KICAgICAgICAgICAgICAgICAgICA8bGkgY2xhc3M9ImZhY2lsaXRpZXMiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZG9scGhpbnNxdWFyZS5jby51ay9ob3VzZS9mYWNpbGl0aWVzLyINCiAgICAgICAgICAgICAgICAgICAgICAgIHRpdGxlPSJGYWNpbGl0aWVzIj5GYWNpbGl0aWVzPC9hPiA8L2xpPg0KICAgICAgICAgICAgICAgICAgICA8bGkgY2xhc3M9ImFwYXJ0bWVudHMiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZG9scGhpbnNxdWFyZS5jby51ay9ob3VzZS9hcGFydG1lbnRzLyINCiAgICAgICAgICAgICAgICAgICAgICAgIHRpdGxlPSJUaGUgYXBhcnRtZW50cyI+QXBhcnRtZW50czwvYT4gPC9saT4NCiAgICAgICAgICAgICAgICAgICAgPGxpIGNsYXNzPSJib29rIj48YSBocmVmPSJodHRwczovL3Jlc2VydmF0aW9ucy5zeW54aXMuY29tL0xCRS9yZXouYXNweD9Ib3RlbD0xODQ4MyZDaGFpbj03MzcxJmxvY2FsZT1lbi1HQiINCiAgICAgICAgICAgICAgICAgICAgICAgIHRpdGxlPSJCb29rIG9ubGluZSI+Qm9vayBvbmxpbmU8L2E+PC9saT4NCiAgICAgICAgICAgICAgICAgICAgPGxpIGNsYXNzPSJjb250YWN0Ij48YSBocmVmPSJodHRwOi8vd3d3LmRvbHBoaW5zcXVhcmUuY28udWsvaG91c2UvY29udGFjdHVzLnBocCINCiAgICAgICAgICAgICAgICAgICAgICAgIHRpdGxlPSJDb250YWN0IHVzIj5Db250YWN0IHVzPC9hPjwvbGk+DQogICAgICAgICAgICAgICAgPC91bD4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiA8ZGl2IGlkPSJtYWluIj4NCiAgPHA+DQogIGQCAQ9kFgICAQ8PFgIeB0xCRURhdGEy1jgAAQAAAP////8BAAAAAAAAAAwCAAAAQUJFQnVzaW5lc3MsIFZlcnNpb249MC4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1udWxsDAMAAABDQnVzaW5lc3MsIFZlcnNpb249NC42LjAuMzI4NTIsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAALFN5bnhpcy5BcHBsaWNhdGlvbi5CRS5CRUJ1c2luZXNzLkxCRS5MQkVEYXRhhAAAAA5faXNJbml0aWFsaXplZA1faG90ZWxDaGFuZ2VkFF9jdXN0b21lckluZm9DaGFuZ2VkDF9sb2dpbkZhaWxlZAtfbG9naW5FbWFpbA5faG90ZWxBdHRyRGF0YQhfaG90ZWxJRAhfY2hhaW5JRAlfaEFsaWFzSUQJX2NBbGlhc0lECV9hbHRTaGVsbAxfb3JpZ0hvdGVsSUQOX29yaWdIb3RlbE5hbWUOX2hvdGVsSXNBY3RpdmUJX2Rlc3RDb2RlCV9yZXpMZXZlbA9fcGF0aFRha2VuTGV2ZWwKX3N0ZXBGaWxlcxBfYnJlYWRDcnVtYnNGaWxlD19jb25maWdGaWxlUGF0aAdfbGFuZ0lEB19sb2NhbGUKX2hvdGVsR3VpZApfY2hhaW5HdWlkCV9kZXN0R3VpZAhfcmV6R3VpZApfaG90ZWxOYW1lCl9ob3RlbENvZGUKX2NoYWluTmFtZQlfZGVzdE5hbWUMX3JlelN0YXR1c0lECl9jb25maXJtTm8JX2NhbmNlbE5vEl9jYWxlbmRhclN0YXJ0RGF0ZQxfYXJyaXZhbERhdGUOX2RlcGFydHVyZURhdGUJX25pZ2h0UXR5CV9hZHVsdFF0eQlfY2hpbGRRdHkKX2p1bmlvclF0eQpfaW5mYW50UXR5Cl9zZW5pb3JRdHkIX3Jvb21RdHkRX3BhY2thZ2VEYXRhQXJyYXkSX3BhY2thZ2VUb3RhbFByaWNlCl9wcm9tb0NvZGULX2lhdGFOdW1iZXIQX3ZhbGlkSWF0YU51bWJlcghfYWdlbnRJRA9fdmFsaWRBZ2VudEd1aWQKX2dyb3VwQ29kZQ5fc3ViU291cmNlQ29kZQ1fYWxsb3dlZFJhdGVzDV9hbGxvd2VkUm9vbXMNX2F2ZXJhZ2VQcmljZRBfZmlyc3ROaWdodFByaWNlC190b3RhbFByaWNlEl90b3RhbFByaWNlV2l0aFRheA1fZGF0ZVJhdGVMaXN0DV9kYWlseVRheExpc3QOX2RhaWx5TWVhbExpc3QJX3JhdGVDb2RlCV9yYXRlR3VpZAlfcmF0ZU5hbWURX2lzU3VwcHJlc3NlZFJhdGUJX3Jvb21Db2RlCV9yb29tR3VpZAlfcm9vbU5hbWUOX3Jvb21Hcm91cENvZGUOX3Jvb21Hcm91cEd1aWQKX2ZpbHRlckJBUhVfaGFzQXZhaWxhYmxlUGFja2FnZXMSX2Jvb2tpbmdQb2xpY3lHdWlkEV9jYW5jZWxQb2xpY3lHdWlkD19jdXJyZW5jeVJhdGVJRA9fY3VycmVuY3lQcmVmaXgUX2hvdGVsQ3VycmVuY3lQcmVmaXgNX2N1cnJlbmN5Q29kZQlfY3VzdEd1aWQNX2N1c3RMb2NhdGlvbgpfZXh0Q3VzdENEBl90aXRsZQlfZnVsbE5hbWUKX2ZpcnN0TmFtZQ5fbWlkZGxlSW5pdGlhbAlfbGFzdE5hbWUNX2J1c2luZXNzTmFtZQ1fYnVzaW5lc3NVbml0CV9hZGRyZXNzMQlfYWRkcmVzczIJX2FkZHJlc3MzBV9jaXR5CF96aXBDb2RlB19waG9uZTEEX2ZheAhfc3RhdGVJRAZfc3RhdGUKX2NvdW50cnlJRAhfY291bnRyeQZfZW1haWwJX3Bhc3N3b3JkDF9jb250YWN0TmFtZRFfbWVtYmVyc2hpcE51bWJlcg5fdXNlQ2FyZE9uRmlsZQtfaXNDQ0NoYW5nZRBfcGF5bWVudFR5cGVHdWlkC19jYXJkVHlwZUlEDV9jYXJkVHlwZURlc2MRX21hc2tlZENhcmROdW1iZXIPX2Z1bGxDYXJkTnVtYmVyDV9zZWN1cml0eUNvZGUJX2V4cE1vbnRoCF9leHBZZWFyD19jYXJkRXhwaXJhdGlvbg9fY2FyZEhvbGRlck5hbWUQX3JlelJvb21TZXJ2aWNlcxxfcmV6Um9vbVNlcnZpY2VzRGVzY3JpcHRpb25zDF9yZXpDb21tZW50cwZfb3B0SW4OX3VwZGF0ZVByb2ZpbGUKX3RheEFtb3VudApfZmVlQW1vdW50Dl9zdGF5VGF4QW1vdW50Dl9tYXJrZXRTZWdtZW50C19hcnJpdmVUaW1lEV9hcnJpdmVUeXBlTnVtYmVyDl9hcnJpdmVBaXJsaW5lGF9hcnJpdmVMb2NhbFRlcm1pbmFsQ29kZRZfYXJyaXZlSG90ZWxUcmFuc3BDb2RlC19kZXBhcnRUaW1lEV9kZXBhcnRUeXBlTnVtYmVyDl9kZXBhcnRBaXJsaW5lAAAAAAEEAAAAAAEAAQABBAQDAQEAAQMDAwMBAQEBAAEBAAAAAAAAAAAAAAQBAQEAAQABAQYGAQEBAQEBAQEDAQABAwEBAwAAAwMAAQEBAwEBAQEBAQEBAQEBAQEBAQEAAQABAQEBAQAAAwABAQEBAQEBAQEBAQAAAQEBBAEBAQEBAQEBAQEBAS1TeW54aXMuQXBwbGljYXRpb24uQkUuQkVCdXNpbmVzcy5MQkUuQXR0ckRhdGECAAAACAgICAgBNlN5bnhpcy5BcHBsaWNhdGlvbi5CRS5CRUJ1c2luZXNzLkVudW1lcmF0aW9ucy5SZXpMZXZlbAIAAAA2U3lueGlzLkFwcGxpY2F0aW9uLkJFLkJFQnVzaW5lc3MuRW51bWVyYXRpb25zLlJlekxldmVsAgAAABxTeXN0ZW0uQ29sbGVjdGlvbnMuSGFzaHRhYmxlCAtTeXN0ZW0uR3VpZAtTeXN0ZW0uR3VpZAtTeXN0ZW0uR3VpZAtTeXN0ZW0uR3VpZAgNDQ0ICAgICAgIMlN5bnhpcy5BcHBsaWNhdGlvbi5CRS5CRUJ1c2luZXNzLkxCRS5QYWNrYWdlRGF0YVtdAgAAAAEBC1N5c3RlbS5HdWlkAQtTeXN0ZW0uR3VpZAtTeXN0ZW0uR3VpZAEBC1N5c3RlbS5HdWlkC1N5c3RlbS5HdWlkCAtTeXN0ZW0uR3VpZAgIAQELU3lzdGVtLkd1aWQIAQE2U3lueGlzLkVudGVycHJpc2UuQnVzaW5lc3MuUmF0ZXMuTWFya2V0U2VnbWVudENvZGVUeXBlAwAAAAIAAAABAQAACgX8////LVN5bnhpcy5BcHBsaWNhdGlvbi5CRS5CRUJ1c2luZXNzLkxCRS5BdHRyRGF0YR4AAAAXX0Rpc3BsYXlQcmljZVJvdW5kaW5nSUQUX0Rpc3BsYXlBdmVyYWdlUHJpY2UXX0lzRGlzcGxheUNvZGVzRXhwYW5kZWQVX0lzSWF0YVRleHRCb3hWaXNpYmxlFl9Jc0dyb3VwVGV4dEJveFZpc2libGUWX0lzUHJvbW9UZXh0Qm94VmlzaWJsZRJfTW9udGhzT2ZJbnZlbnRvcnkOX0lzUG9saWN5UG9wdXAaX0lzTXVsdGlSb29tQm9va2luZ0FsbG93ZWQRX0lzQXZhaWxDYWxIaWRkZW4PX1V0Y0RlbHRhT2Zmc2V0Fl9NYXhpbXVtTnVtYmVyT2ZOaWdodHMWX01heGltdW1OdW1iZXJPZkFkdWx0cxhfTWF4aW11bU51bWJlck9mQ2hpbGRyZW4VX01heGltdW1OdW1iZXJPZlJvb21zFl9EaXNhYmxlQ2hpbGRTZWxlY3Rpb24UX0F2YWlsUmVzdWx0U29ydFR5cGUWX0Rlc3RSZXN1bHREaXNwbGF5VHlwZRBfRGlzcGxheUFsdEF2YWlsFF9EaXNwbGF5VG90YWxXaXRoVGF4E19BbHdheXNTaG93QWxsUmF0ZXMWX1Nob3dQYWNrYWdlU2VsZWN0U3RlcBFfQ0NPcHRpb25hbExhbmdJRBdfSXNTZWN1cml0eUNvZGVSZXF1aXJlZA9fUHJlc2VsZWN0T3B0SW4XX1ByZXNlbGVjdFVwZGF0ZVByb2ZpbGUVX0Rpc3BsYXlUcmFuc3BvcnRJbmZvFF9Jc1BvbGljeUFja1JlcXVpcmVkFl9EaXNwbGF5TnVtYmVyT2ZOaWdodHMVX0lzVGF4RGlzcGxheUV4cGFuZGVkAAAAAAAAAAAAAAAAAAAAAAQEAAAAAAAAAAAAAAAACAEBAQEBCAEBAQYICAgIATZTeW54aXMuRW50ZXJwcmlzZS5CdXNpbmVzcy5Qcm9kdWN0cy5Qcm9kdWN0U29ydGluZ1R5cGUDAAAARFN5bnhpcy5FbnRlcnByaXNlLkJ1c2luZXNzLkhvdGVsR3JvdXBzLkRlc3RpbmF0aW9uUmVzdWx0c0Rpc3BsYXlUeXBlAwAAAAEBAQEIAQEBAQEBAQIAAAD/////AAAAAAEAAAAAAQAAAAAAAAAAAABZAAAABgAAABIAAAAFAAAAAAX7////NlN5bnhpcy5FbnRlcnByaXNlLkJ1c2luZXNzLlByb2R1Y3RzLlByb2R1Y3RTb3J0aW5nVHlwZQEAAAAHdmFsdWVfXwAIAwAAAAAAAAAF+v///0RTeW54aXMuRW50ZXJwcmlzZS5CdXNpbmVzcy5Ib3RlbEdyb3Vwcy5EZXN0aW5hdGlvblJlc3VsdHNEaXNwbGF5VHlwZQEAAAAHdmFsdWVfXwAIAwAAAAEAAAAAAQEBAAAAAAEAAAABAQEzSAAAyxwAAAAAAAAAAAAACjNIAAAGBwAAACFEb2xwaGluIEhvdXNlIFNlcnZpY2VkIEFwYXJ0bWVudHMBCgX4////NlN5bnhpcy5BcHBsaWNhdGlvbi5CRS5CRUJ1c2luZXNzLkVudW1lcmF0aW9ucy5SZXpMZXZlbAEAAAAHdmFsdWVfXwAIAgAAAAEAAAAB9/////j///8BAAAACQoAAAAGCwAAADMvTEJFL1JlelByb2Nlc3MvQnJlYWRDcnVtYnMvRGVmYXVsdEJyZWFkQ3J1bWJzLmFzY3gGDAAAAD5cXDEwLjIwLjgyLjExXHN5bnhpc19XZWJpbWFnZXNcaG90ZWxcMTg0ODNcbGF5b3V0XEJFQ29uZmlnLnhtbAEAAAAGDQAAAAVlbi1HQgTy////C1N5c3RlbS5HdWlkCwAAAAJfYQJfYgJfYwJfZAJfZQJfZgJfZwJfaAJfaQJfagJfawAAAAAAAAAAAAAACAcHAgICAgICAgIWnplS9yzMS5CitRuzODwhAfH////y////6dmcbrvKa0+WUu1LNWXTOgHw////8v///wAAAAAAAAAAAAAAAAAAAAAB7/////L///8AAAAAAAAAAAAAAAAAAAAACQcAAAAGEwAAAAZMSFJET0wGFAAAAA5Eb2xwaGluIEhvdXNlIAoAAAAABhUAAAAACRUAAAAAwLeRkZHKCAAA3wrJpsqIAMBINZKnyogBAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAACgoKCgAKAAoKCgoKCgoKCgoKCgHq////8v///wAAAAAAAAAAAAAAAAAAAAAKAAoB6f////L///8AAAAAAAAAAAAAAAAAAAAACgoB6P////L///8AAAAAAAAAAAAAAAAAAAAAAAAB5/////L///8AAAAAAAAAAAAAAAAAAAAAAeb////y////AAAAAAAAAAAAAAAAAAAAAAsAAAAGGwAAAANHQlAJGwAAAAYcAAAAA0dCUAHj////8v///wAAAAAAAAAAAAAAAAAAAAAKCgoKCgoKCgoKCgoKCgoKAAAAAAoAAAAACgoKCgoAAAHi////8v///wAAAAAAAAAAAAAAAAAAAAAAAAAACgoKCRUAAAAKCgoKCgoKAAEKCgoF4P///zZTeW54aXMuRW50ZXJwcmlzZS5CdXNpbmVzcy5SYXRlcy5NYXJrZXRTZWdtZW50Q29kZVR5cGUBAAAAB3ZhbHVlX18ACAMAAAACAAAACgoKCgoKCgoECgAAABxTeXN0ZW0uQ29sbGVjdGlvbnMuSGFzaHRhYmxlBwAAAApMb2FkRmFjdG9yB1ZlcnNpb24IQ29tcGFyZXIQSGFzaENvZGVQcm92aWRlcghIYXNoU2l6ZQRLZXlzBlZhbHVlcwAAAwMABQULCBxTeXN0ZW0uQ29sbGVjdGlvbnMuSUNvbXBhcmVyJFN5c3RlbS5Db2xsZWN0aW9ucy5JSGFzaENvZGVQcm92aWRlcgjsUTg/FQAAAAoKLwAAAAkhAAAACSIAAAAQIQAAABMAAAAJIwAAAAkkAAAACSUAAAAJJgAAAAknAAAACSgAAAAJKQAAAAkqAAAACSsAAAAJLAAAAAktAAAABi4AAAAHY2hhaW5JRAkvAAAACTAAAAAJMQAAAAkyAAAABjMAAAAHaG90ZWxJRAk0AAAACTUAAAAQIgAAABMAAAAJNgAAAAk3AAAACTgAAAAJOQAAAAk6AAAACTsAAAAJPAAAAAk9AAAACT4AAAAJPwAAAAlAAAAACAjLHAAACUEAAAAJQgAAAAlDAAAACUQAAAAICDNIAAAJRQAAAAlGAAAABSMAAAA8U3lueGlzLkFwcGxpY2F0aW9uLkJFLkJFQnVzaW5lc3MuRW51bWVyYXRpb25zLlJlelByb2Nlc3NTdGVwAQAAAAd2YWx1ZV9fAAgCAAAAjhoGAAEkAAAAIwAAAI0aBgABJQAAACMAAACMGgYAASYAAAAjAAAAixoGAAEnAAAAIwAAAIoaBgABKAAAACMAAACJGgYAASkAAAAjAAAAiBoGAAEqAAAAIwAAAIcaBgABKwAAACMAAACGGgYAASwAAAAjAAAAhRoGAAEtAAAAIwAAAIQaBgABLwAAACMAAACCGgYAATAAAAAjAAAAgRoGAAExAAAAIwAAAOQaBgABMgAAACMAAACDGgYAATQAAAAjAAAAlBoGAAE1AAAAIwAAAAAAAAAENgAAABxTeXN0ZW0uQ29sbGVjdGlvbnMuQXJyYXlMaXN0AwAAAAZfaXRlbXMFX3NpemUIX3ZlcnNpb24FAAAICAlHAAAAAQAAAAEAAAABNwAAADYAAAAJSAAAAAEAAAABAAAAATgAAAA2AAAACUkAAAABAAAAAQAAAAE5AAAANgAAAAlKAAAAAQAAAAEAAAABOgAAADYAAAAJSwAAAAEAAAABAAAAATsAAAA2AAAACUwAAAABAAAAAQAAAAE8AAAANgAAAAlNAAAAAQAAAAEAAAABPQAAADYAAAAJTgAAAAEAAAABAAAAAT4AAAA2AAAACU8AAAABAAAAAQAAAAE/AAAANgAAAAlQAAAAAQAAAAEAAAABQAAAADYAAAAJUQAAAAEAAAABAAAAAUEAAAA2AAAACVIAAAABAAAAAQAAAAFCAAAANgAAAAlTAAAAAQAAAAEAAAABQwAAADYAAAAJVAAAAAEAAAABAAAAAUQAAAA2AAAACVUAAAABAAAAAQAAAAFFAAAANgAAAAlWAAAAAQAAAAEAAAABRgAAADYAAAAJVwAAAAEAAAABAAAAEEcAAAAEAAAACVgAAAANAxBIAAAABAAAAAlZAAAADQMQSQAAAAQAAAAJWgAAAA0DEEoAAAAEAAAACVsAAAANAxBLAAAABAAAAAlcAAAADQMQTAAAAAQAAAAJXQAAAA0DEE0AAAAEAAAACV4AAAANAxBOAAAABAAAAAlfAAAADQMQTwAAAAQAAAAJYAAAAA0DEFAAAAAEAAAACWEAAAANAxBRAAAABAAAAAliAAAADQMQUgAAAAQAAAAJYwAAAA0DEFMAAAAEAAAACWQAAAANAxBUAAAABAAAAAllAAAADQMQVQAAAAQAAAAJZgAAAA0DEFYAAAAEAAAACWcAAAANAxBXAAAABAAAAAloAAAADQMFWAAAADBTeW54aXMuQXBwbGljYXRpb24uQkUuQkVCdXNpbmVzcy5MQkUuTEJFU3RlcERhdGEFAAAACV9zdGVwRmlsZQVfc3RlcAlfc3RlcEhUTUwMX3N0ZXBTdWJGaWxlFF9pc0N1c3RvbVN0ZXBTdWJGaWxlAQQBAQA8U3lueGlzLkFwcGxpY2F0aW9uLkJFLkJFQnVzaW5lc3MuRW51bWVyYXRpb25zLlJlelByb2Nlc3NTdGVwAgAAAAECAAAABmkAAAA8fi9SZXpQcm9jZXNzL0NoZWNrQXZhaWxhYmlsaXR5L0RlZmF1bHRDaGVja0F2YWlsYWJpbGl0eS5hc2N4AZb///8jAAAAjhoGAAoKAAFZAAAAWAAAAAZrAAAAMn4vUmV6UHJvY2Vzcy9Db25maXJtYXRpb24vRGVmYXVsdENvbmZpcm1hdGlvbi5hc2N4AZT///8jAAAAjRoGAAoKAAFaAAAAWAAAAAZtAAAALX4vUmV6UHJvY2Vzcy9FcnJvclBhZ2VzL0RlZmF1bHRFcnJvclBhZ2UuYXNjeAGS////IwAAAIwaBgAKCgABWwAAAFgAAAAJaQAAAAGQ////IwAAAIsaBgAKCgABXAAAAFgAAAAGcQAAAEB+L1JlelByb2Nlc3MvQXZhaWxhYmlsaXR5UmVzdWx0cy9EZWZhdWx0QXZhaWxhYmlsaXR5UmVzdWx0cy5hc2N4AY7///8jAAAAihoGAAoKAAFdAAAAWAAAAAlpAAAAAYz///8jAAAAiRoGAAoKAAFeAAAAWAAAAAZ1AAAAMn4vUmV6UHJvY2Vzcy9SZXpTZWFyY2gvRGVmYXVsdFJlelNlYXJjaERldGFpbC5hc2N4AYr///8jAAAAiBoGAAoKAAFfAAAAWAAAAAZ3AAAAKn4vUmV6UHJvY2Vzcy9SZXpTZWFyY2gvRGVmYXVsdFJlekxpc3QuYXNjeAGI////IwAAAIcaBgAKCgABYAAAAFgAAAAGeQAAACx+L1JlelByb2Nlc3MvUmV6U2VhcmNoL0RlZmF1bHRSZXpTZWFyY2guYXNjeAGG////IwAAAIYaBgAKCgABYQAAAFgAAAAJaQAAAAGE////IwAAAIUaBgAKCgABYgAAAFgAAAAGfQAAACZ+L1JlelByb2Nlc3MvUmV2aWV3L0RlZmF1bHRSZXZpZXcuYXNjeAGC////IwAAAIQaBgAKCgABYwAAAFgAAAAJcQAAAAGA////IwAAAIIaBgAKCgABZAAAAFgAAAAJaQAAAAF+////IwAAAIEaBgAKCgABZQAAAFgAAAAJaQAAAAF9////IwAAAOQaBgAKCgABZgAAAFgAAAAGhAAAADJ+L1JlelByb2Nlc3MvQ3VzdG9tZXJJbmZvL0RlZmF1bHRDdXN0b21lckluZm8uYXNjeAF7////IwAAAIMaBgAKCgABZwAAAFgAAAAGhgAAADR+L1JlelByb2Nlc3MvUGFja2FnZVNlbGVjdC9EZWZhdWx0UGFja2FnZVNlbGVjdC5hc2N4AXn///8jAAAAlBoGAAoKAAFoAAAAWAAAAAlpAAAAAXf///8jAAAAAAAAAAoKAAtkFgJmD2QWAgIBD2QWBgIDD2QWAgIDDxBkZBYAZAIPD2QWAgIBD2QWAgIBDxBkZBYBZmQCFw9kFgYCAQ8PFgIfAAUEUHJldmRkAgMPEGRkFgFmZAIFDw8WAh8ABQROZXh0ZGQCAg8WAh8ABasDDQogICA8c2NyaXB0IHNyYz1odHRwczovL3NlYWwudmVyaXNpZ24uY29tL2dldHNlYWw/aG9zdF9uYW1lPXJlc2VydmF0aW9ucy5zeW54aXMuY29tJnNpemU9TSZ1c2VfZmxhc2g9WUVTJnVzZV90cmFuc3BhcmVudD1ZRVMmbGFuZz1lbj48L3NjcmlwdD4NCiAgPC9wPg0KIDwvZGl2Pg0KDQo8cCBpZD0iZm9vdGVyIj48YSBocmVmPSJodHRwOi8vd3d3LmRvbHBoaW5zcXVhcmUuY28udWsvaG91c2UvdGVybXMucGhwIiB0aXRsZT0iUmVhZCBvdXIgdGVybXMgYW5kIGNvbmRpdGlvbnMiPlRlcm1zIGFuZCBjb25kaXRpb25zPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly93d3cuZG9scGhpbnNxdWFyZS5jby51ay9ob3VzZS9zaXRlbWFwLnBocCIgdGl0bGU9IlZpZXcgdGhlIHNpdGVtYXAiPlNpdGVtYXA8L2E+PC9wPgo8L2Rpdj4NCjwvdGQ+PC90cj48L3RhYmxlPmRk3olXT9sK3/WmfcohYIY5fZQuFMQ=");
>>
That is ASP.NET's way of preserving the view state of a web form from
one request to another. I'm not positive, but I think it's just a
base64 encoded string. It isn't the equivalent of sessions in PHP, as
ASP.NET has its own session handler. I think it would be more
equivalent to storing a Zend_Form object in PHP sessions so that it
can handle events from page to page.
Andrew
--- End Message ---
--- Begin Message ---
Thanks Chris and Andrew,
An interesting article here on VIEWSTATE in asp:
http://www.dotnetjohn.com/articles.aspx?articleid=71 refers to MAC
encoding using SHA1 or MD5, alternatively Triple DES symmetric
algorithm. However, in either event, VIEWSTATE seems to be just what is
sent by the server which the server expects to receive back unmodified.
I tried the same input form as on the target server on a test page on my
site with the action on the form to the target server and that works OK
to get the results page on the target server. I have also tested on my
server that the CURL POST variables are giving sensible inputs like the
ones that the page would produce on GET. In the process, I also learned
that colons in the POST variable names don't need to be changed for HTML
encoding, spaces in the variable values do need to be, anyway the POST
variables seem to work OK as I said. Whatever is or is not being sent
by the script as opposed to the input form on a test page of my site is
the difference that I am looking for. I will try another site see can I
learn anything in the process.
Oh, and decoding the string as suggested
(print_r(base64_decode($view_state_string));) gives one value in the
array and a mixture of English and other characters plus most of the
page: eg d ....2Ö8ÿÿÿÿ Version=0.0.0.0, and other
characters that do not copy to this email etc. As above, I don't see
that this is interfering with CURLing the results page if it is simply
sent back in the post.
John
--- End Message ---
--- Begin Message ---
On Tue, 2008-07-01 at 13:26 -0700, Brian Dunning wrote:
> I have a web page that lists "most recent comments" in a left margin.
> Sometimes people post long URLs, or even just really really long
> words, that force that margin to display way too wide, screwing up the
> page layout. Is there a way to make sure URLs or other text in a
> string gets split up so this doesn't happen?
>
> If there's a CSS solution that's better than a PHP solution I'll take
> that too. :-)
>
For URLs you can do a tinyurl-type solution. Quite easy in fact. Just
save the long url in a db table, along with a short url (say a
4-character random string). Then do a page that looks up the short url
and redirects to a long url (eg. http://www.myblog.com/r?id=Sve7
redirects to http://www.veryverylongurl.com/blahblahblah.php). For extra
points you can make the short url look like http://tiny.myblog.com/Sve7.
Just remember to put the short url creation in a loop that checks that
the short url isn't in the DB already and repeat if it is.
For long words, you could explode the words into an array, and if the
words are longer than a certain length, insert a hyphen and space for
your wrap. Then just implode back into your string and bob's your uncle.
Anyhow that's how I'd do it.
J
--- End Message ---
--- Begin Message ---
On Wed, 2008-07-02 at 08:23 +0200, Jason Norwood-Young wrote:
> For URLs you can do a tinyurl-type solution.
Dur, just realised it's only *display* that you're worried about so
shortening the url isn't really an issue. It's too early in the
morning...
--- End Message ---
--- Begin Message ---
Hi !
I have a very weird issue since the last Apache upgrade (-> 2.2.8-r3, a month ago), but I'm not sure it is related (well, I'm
pretty sure it's not).
Like many people, I've written an application that use PHP session variables, like
$_SESSION["my_variable"].
Sometimes (it doesn't happen all the time), _some_ of these variables are not written in the session file and they are lost
after a simple header("Location:...); (same domain). The session file is in the right directory (permissions are fine), but some
of my variables are missing.
The facts :
- Apache 2.2.9 + PHP 5.2.6_rc4 running on a Gentoo (up-to-date)
- all my scripts begin with session_start(). I've tried to add session_write_close() before every header(Location:...) call, it
doesn't help.
- I didn't change anything in my program (it has been running just fine for 2 years), it just began to fail from time to time (I
would say 10 times a day). There is no hidden unset() function : it would fail for everyone.
- these variables are all set correctly, and they don't have reserved names.
- only a few variables disappear, but they are always the same ones (could it
depend on their position in the session file ?!?)
- the session files are very small (max 100ko)
- it seems that it doesn't depend on the browser, but IE6 and IE7 seem to be the most affected ones (it may be because my users
mostly use these browsers).
- I can't reproduce this issue from my local network (any OS/browser - it would
be too easy :)
- reverting to the previous stable Apache and/or PHP versions doesn't help.
- I didn't change any php.ini directive.
Any idea ?
Thanks !
PS: if you need more details, just ask. The only thing I can't do is pasting
the code : the scripts are quite huge.
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Waynn Lue [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 01, 2008 11:06 PM
> To: [EMAIL PROTECTED]
> Subject: [SPAM] [PHP] FIFO files on PHP?
> Importance: Low
>
> I'm trying to build a queue out using FIFO files (someone on the MySQL
> list suggested checking them out instead of using the database), but
> I'm running into a problem because of the synchronous fwrite call.
> Here's the code:
>
> $fifoFile = '/tmp/fifo';
> if (!file_exists($fifoFile)) {
> posix_mkfifo($fifoFile, 0600);
> }
> $fp = fopen($fifoFile, "w");
> fwrite($fp, "content");
> fclose($fp);
>
> But this will block until something actually reads the pipe. Is there
> any way to write to the pipe, then go away as opposed to waiting until
> something consumes it? Otherwise, I may just go back to a database
> table.
>
> Thanks,
> Waynn
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
Fifo nodes are equivalent to a pipe (|) and have no size on the file
system and therefore the write won't finish until some process reads
from the node. See the man page http://linux.die.net/man/7/fifo .
--- End Message ---
--- Begin Message ---
Hi All,
I want to show one URL at browser and content of different URL.
Like user can see the URL at address bar like http://localhost/test/home/
or http://localhost/test/tech/php/ but content of page will be
http://localhost/test/index.php
The URL of the address bar will never change to
http://localhost/test/index.php
Still a newbie!
Thanks,
Subhranild.
--
View this message in context:
http://www.nabble.com/URL-Rewrite-tp18233803p18233803.html
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
Subhranil wrote:
>
> Hi All,
>
> I want to show one URL at browser and content of different URL.
>
Take a look at apache url rewriting.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
On Wed, Jul 2, 2008 at 6:33 AM, Per Jessen <[EMAIL PROTECTED]> wrote:
> Subhranil wrote:
>
> >
> > Hi All,
> >
> > I want to show one URL at browser and content of different URL.
> >
>
>
> Take a look at apache url rewriting.
>
>
> /Per Jessen, Zürich
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
You could look at using an iframe or frames in general, or ajax call into a
div
--
Bastien
Cat, the other other white meat
--- End Message ---
