I don't believe you'd lose REMOTE_ADDR in FCGI setup, at least I have
never seen it be lost. It is fairly important for many applications
and I'd imagine we would've heard it is missing. The ones missing
often are DOCUMENT_ROOT, PHP_SELF not being quite the same, PATH_INFO
missing or differ
The $_SERVER vars maybe not quite the same as well when comparing
mod_php and fcgi.
I think the vital ones should be the same, though you indeed might lose
some ones like REMOTE_PORT or REMOTE_ADDR - though I checked in my FCGI
setup they seem to be ok.
--
Stanislav Malyshev, Zend Products E
On 12-Jan-07, at 4:12 PM, Stanislav Malyshev wrote:
That said, if my Production environment is mod_php, I want my dev
environment to be mod_php, because I'd rather not find out the hard
way that it makes some subtle but important difference when I get to
QA/staging.
Well, if you develop on Wi
The big one is the HTTP Authentication (?) because, errr, it would
have to pass the password in cleartext through a process that would be
visible to `ps auxwww` ??? So while it's not technically impossible,
FCGI operates by use of pipes, so any data sent back and forth are not
accessible unles
On Sun, January 7, 2007 3:34 pm, Stanislav Malyshev wrote:
>> Well a lot of people develop on windows and deploy on Linux with
>> mod_php. For these people it probably makes more sense using mod_php
>> on
>> windows still.
>
> How it should matter for them - PHP is not supposed to be dependant on
>
Not to drag this thread on any longer, but I think I found the issue.
There is something wrong with Edin's build. A few of the modules do not
have the manifest embedded. I was using bz2 and pdo for testing because
I found that both php_bz2.dll and php_pdo.dll have no embedded manifest.
When I
Not that people should write it like that, but I have seen code in the
wild that uses getallheaders() (Apache only function) to get request
headers instead of using more portable ways.
Oh, I see. If people use Apache-only functions then surely they have to
have Apache :) But since there's a por
Stanislav Malyshev wrote:
> How it should matter for them - PHP is not supposed to be dependant on
> SAPI except for maybe some things in environment variables - which would
> be different on deployment machine anyway?
Not that people should write it like that, but I have seen code in the
wild tha
Well a lot of people develop on windows and deploy on Linux with
mod_php. For these people it probably makes more sense using mod_php on
windows still.
How it should matter for them - PHP is not supposed to be dependant on
SAPI except for maybe some things in environment variables - which woul
Hmm. I know that, in the past, I've had this kind of issue when
trying to distribute modules that use the debug version of the CRT
(which is itself not redistributable). I wonder if that is sneaking
into the build somehow?
--Wez.
On 1/7/07, Rob Richards <[EMAIL PROTECTED]> wrote:
Don't know i
Don't know if any of this will help, but here's what I've been getting
while trying to use VS 2005.
I'm not sure what the difference is between my debug build and the one
Edin released, but when using my own build apache loads everything fine.
Using Apache 2.0.59 for testing. When I change the
Hey Wez,
We have:
_VC_MANIFEST_EMBED_EXE= $(MT) -manifest [EMAIL PROTECTED] -outputresource:$@;1
_VC_MANIFEST_EMBED_DLL= $(MT) -manifest [EMAIL PROTECTED] -outputresource:$@;2
which should embed the manifest. It works for CLI/CGI but somehow does
not work wiht Apache (old CRT). Actually it works
Hi Edin,
It might be that we need to change our manifest for mod_phpx.dll to
make the crt load correctly. IIRC, there was some magical way to do
this based on the resource number you use when you bake the manifest
into the module; position 1 means one thing and position 2 means
another.
I have
Hello,
On 1/7/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Andi Gutmans wrote:
> Btw, today I never recommend running mod_php on Windows and always point
> people to CGI or existing FastCGI implementations.
Well a lot of people develop on windows and deploy on Linux with
mod_php. For these
Andi Gutmans wrote:
Btw, today I never recommend running mod_php on Windows and always point
people to CGI or existing FastCGI implementations.
Well a lot of people develop on windows and deploy on Linux with
mod_php. For these people it probably makes more sense using mod_php on
windows sti
ssage-
>> > From: Andi Gutmans [mailto:[EMAIL PROTECTED]
>> > Sent: Saturday, January 06, 2007 6:20 PM
>> > To: 'Edin Kadribasic'
>> > Cc: 'PHP Internals List'
>> > Subject: RE: [PHP-DEV] Windows build
>> >
>> > Hi
Saturday, January 06, 2007 6:20 PM
> > To: 'Edin Kadribasic'
> > Cc: 'PHP Internals List'
> > Subject: RE: [PHP-DEV] Windows build
> >
> > Hi Edin,
> >
> > The 2% surprises me a lot. We got very different results but
> > it might
Andi Gutmans
Cc: 'PHP Internals List'
Subject: Re: [PHP-DEV] Windows build
Hi Andi,
Turns out the problem is that Apache is building their binaries using
VC6 so wrong CRT gets loaded. The only solution I found was
to tell Windows to load Apache with msvcr80.dll instead of
msvcr.dll by su
mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 06, 2007 6:20 PM
> To: 'Edin Kadribasic'
> Cc: 'PHP Internals List'
> Subject: RE: [PHP-DEV] Windows build
>
> Hi Edin,
>
> The 2% surprises me a lot. We got very different results but
> it might be du
L PROTECTED]
> Sent: Saturday, January 06, 2007 6:20 PM
> To: 'Edin Kadribasic'
> Cc: 'PHP Internals List'
> Subject: RE: [PHP-DEV] Windows build
>
> Hi Edin,
>
> The 2% surprises me a lot. We got very different results but
> it might be due to
IL PROTECTED]
> Sent: Saturday, January 06, 2007 1:28 PM
> To: Andi Gutmans
> Cc: 'PHP Internals List'
> Subject: Re: [PHP-DEV] Windows build
>
> Hi Andi,
>
> Turns out the problem is that Apache is building their binaries using
> VC6 so wrong CRT gets loaded
> A last interesting question; what sort of headaches have you hit loading
> within the ISAPI/IIS environment? I would presume that older/modern IIS
> flavors suffer from similar headaches?
Seems that the least headache solution is to ship binaries built with
VC6. I have not encountered any probl
Edin Kadribasic wrote:
> Hi Andi,
>
> Turns out the problem is that Apache is building their binaries using
> VC6 so wrong CRT gets loaded. The only solution I found was to tell
> Windows to load Apache with msvcr80.dll instead of msvcr.dll by suppling
> a manifest file in Apache bin directory. If
Hello Edin,
ok, i thought you would use the newer stuff already. Maybe if you have all
withstaticruntime it *could* work. But I happen to have thesekinds of
problems ofwork as well - a lot unfortunatley.
best regards
marcus
Saturday, January 6, 2007, 10:14:17 PM, you wrote:
> William A. Rowe,
Hi Andi,
Turns out the problem is that Apache is building their binaries using
VC6 so wrong CRT gets loaded. The only solution I found was to tell
Windows to load Apache with msvcr80.dll instead of msvcr.dll by suppling
a manifest file in Apache bin directory. If you crate
Apache.exe.manifest that
Hi Edin,
Thanks for trying to get this to work!
I think eventually it'll be the right move to go to VC8 but I agree that if
it risks a successful 5.2.1 release then it might not be worth doing that
right now. If you can share with us a reproducing case we can try and look
into it and see if we ca
William A. Rowe, Jr. wrote:
> Marcus Boerger wrote:
>> Hello Ilia,
>>
>> weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind
>> 6.0 long ago :-)
>
> For reference, ActiveState python is built on Studio 2003 al la 7.1, while
> their perl is still built VC 6, if you are looking
Marcus Boerger wrote:
> Hello Ilia,
>
> weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind
> 6.0 long ago :-)
For reference, ActiveState python is built on Studio 2003 al la 7.1, while
their perl is still built VC 6, if you are looking to coexist more peacefully
with one or
From what I know Edin uses VC++ 6.0 which works just fine for our
needs. So, I see no reason to move away from that unless someone can
present a really good reason why it should be done.
On 6-Jan-07, at 2:48 PM, Marcus Boerger wrote:
Hello Ilia,
weel 2002 aka 7.0 or 2003 aka 7.1 are pre
Hello Ilia,
weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind
6.0 long ago :-)
best regards
marcus
Saturday, January 6, 2007, 5:44:55 AM, you wrote:
> Edin,
> Thanks for the detailed analysis and spending time analyzing the
> issue. Based on what you've said I think ou
Edin Kadribasic wrote:
>
> I can get PHP to work fine on the command line, both cgi and cli. It
> also works fine under IIS using fastcgi. But loading sapi dll into a
> webserver (not using php.exe or php-cgi.exe) works for the sapi itself,
> but trying to load any extensions via php.ini fails mis
This sounds like a sane approach. My own 2c is that your failure to load
represents a failure to correctly package the .manifest data of the
individual modules; perhaps this is due to the individual modules requiring
an entry for php5ts.dll? Without digging deeper, it is probably most sane
to shi
Edin,
Thanks for the detailed analysis and spending time analyzing the
issue. Based on what you've said I think our best option is to go
back to VC++ 6.0 for this release, we are too far along in the
release cycle to experiment with things. Perhaps for the next release
we can revisit the
Hi,
On 1/6/07, Edin Kadribasic <[EMAIL PROTECTED]> wrote:
It seems that VC++ 8.0 (Visual Studio 2005) brings more trouble that its
worth. Mainly the way it deals with the C runtime. After spending hours
and hours of trying to figure out the way to make PHP work under Apache
on Windows and be abl
Stas,
Frank already has a patch for this that should be committed shortly.
On 1-Dec-06, at 2:38 PM, Stanislav Malyshev wrote:
Latest patch to php_scandir:
http://cvs.php.net/viewvc.cgi/php-src/main/php_scandir.c?
r1=1.12.2.1&r2=1.12.2.1.2.1
Seems to break windows build in two places:
main
>
> You also need:
> - bindlib_w32 [http://www.php.net/extra/bindlib_w32.zip]
>
> got it.
> changed configuration to release. tried to build the solution:
>
> d:\dev\php_source\bindlib_w32\nsap_addr.c(37): error C2491: 'isxdigit' :
> definition of dllimport function not allowed
>
> i`ve commente
From: Steph
> nb that meant downgrading both libxml2 and iconv here..
I dont think going with the 2.6.x branch for libxml is a good idea yet.
Would like it to be out a while longer before using it for releases. It has
some major changes in it as well as a bunch of new features so probably
better
Rob,
I had severe problems with building on win98 because the batch file doesn't
work here AT ALL. Following Frank's change I found that phpts.def was left
permanently empty for me (says something about how long it is since I tested
sqlite, eh?) even though php -m showed both libxml and sqlite mo
From: Frank M. Kromann
> I'm using iconv 1.9.1 and I get problems with _libiconv_version it does'nt
> seam to be in the lib file.
>
> If I remove this from the exports I can build and link php4dllts.lib and
> php_xls.dll without problems but not php_iconv.dll.
Following up on this as it turned ou
Hi Rob,
I'm using iconv 1.9.1 and I get problems with _libiconv_version it does'nt
seam to be in the lib file.
If I remove this from the exports I can build and link php4dllts.lib and
php_xls.dll without problems but not php_iconv.dll.
I'll try to resolve this.
I also move the @echo off to the
40 matches
Mail list logo
