[PHP-DEV] followup: mod_negotiation and php
As a followup, I'd like to document what worked (for me) to address the problem. The issue, in summary, is that mod_negotiation thinks that PHP produces content of type application/x-httpd-php. It usually produces text/html of course, but there's no way for it to know that. mod_negotiation has infrastructure to consider a few other mime as pseudo html during the negotiation phase. Changing INCLUDES_MAGIC_TYPE in apache:src/include/httpd.h to application/x-httpd-php results in the behaviour you would hope for. I haven't got the chops to try to turn this into an acceptable patch. But the hack could work for others. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mod_negotiation and 406 and php
I'm using Apache mod_negotiation to eliminate file extensions from my site, e.g. http://tinyplanet.ca/services/development This works great for dynamic features too, as I get pathinfo for free. No more ?article_id=92 business for me. Anyway. Google hates my guts for doing this. Why? Well, it sends Accept: text/plain,text/html in its HTTP requests. This causes Apache to a) issue a 406 no suitable content found error, and b) not serve my content to google for indexing. Greaaat. If I feed such a request to Apache, it says: An appropriate representation of the requested resource /services/dev could not be found on this server. Available variants: ul lia href=dev.htmldev.html/a , type application/x-httpd-php, language en ^^^ Which is, of course, correct. Of course, if I change the content-type of .html files, then PHP won't parse them. I'm at a bit of a loss to figure out how to fix this. Suggestions welcome. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Do database resources sleep at night?
John Lim ([EMAIL PROTECTED]) wrote: My suspicion is that persistent resources are only cleaned up when the child process dies, while non-persistent resources are closed immediately at the end of the page/script. Does anyone know the correct answer? Correct. If you can spare the time, I would be grateful for an answer to the following questions too: 2. If resources are not cleaned up until the apache child process dies, what will happen in multi-threaded servers like Apache 2 and IIS? I don't know. The Right Thing To Do would be to use a connection pool, with the connection resource borrowed by scripts, then released when they're done. AOLServer does this. 3. Are persistent resources locked exclusively by an executing script until the script completes when the resources become available for other scripts, or can persistent resources be shared by multiple concurrent scripts? This question doesn't make sense in the current apache architecture. Each apache child gets its own persistent connections, which are not shared with other apache children. -Steve -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
Zeev Suraski ([EMAIL PROTECTED]) wrote: I don't think we can change the behavior of empty() at this stage... isempty()? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
Think about whether in each of these cases it would have happened if the
developers of the app had developed with E_NOTICE on. In a high number of
these cases it probably wouldn't. And if this number is close to 100%,
then it would point to the fact that there is another less destructive
solution here.
This is why I want to go through and investigate existing PHP code and
have a look.
I'm a user of PHP, who would describe himself as approaching expert
in my knowledge.
I took a suggestion from earlier in this thread, and turned off
E_NOTICE. An excellent idea. I found a few holes in some of my code,
which I was glad to repair, and grateful to the language for pointing
out to me.
The suggestion to turn off register_globals by default is an extremely
bad one. It would make using PHP nothing short of a pain in the ass,
break vast amounts of code, and not improve a whole lot. I _LIKE_ that
I can GET or POST to a page, and the variables will still come from the
right place.
While considering the security angle, it's important to notice that
there is a tradeoff between a secure system and a functional system,
and that for some people, security just doesn't rate: either the
function (e.g. register_globals) is too valuable, or the downside of a
security failure is just not all that great. A lot of people prefer
function over security, and would find it an unwelcome arrogance if PHP
forced them to twiddle some settings to get it back.
Finally, a small note from my PHP programming experiences:
In order to code with E_ALL, idioms like this:
if ($x)
will produce warnings if $x is not set. If you don't want the
warnings, you have to replace it with:
if (isset($x) $x) {
}
if it's set and it's true...? ugh.
One is then tempted to look for replacement functions in the
library, and immediately hits upon empty.
if (!$empty)
But as can be seen from the table at
http://bang.dhs.org/~svanegmond/logictest.php , empty()
returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
of empty() are a good replacement for the warning-generating cast to
boolean.
This tends to make E_NOTIFY more trouble than it's worth... which is
why people (including the Debian package maintainer) keep it disabled.
Thus I recommend that empty() be fixed to return false for boolean
values. Failing that, that a non-warning-generating logical
equivalent of cast-to-boolean be provided.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Security techniques
I was going to reply to Phil Driscoll's post (from Friday) about E_SECURITY warning level, but thought it might belong better in a different thread. This thread is for collecting some ideas for security enhancements that can happen in PHP, besides the already-known register_globals. My idea: Have PHP reject (fail to process, die, whatever) a hit that is anomalous. Definitions of anomalous: 1. GET variables set while METHOD != GET i.e. form action=foo.php?x=1 method=POST ... /form This is a major point of attack identified in the study in Scarlet. Although I can imagine the above being a programming technique someone, somewhere, has used, future releases might reasonably default to rejecting hits that attempt it. 2. when a uploaded file fails is_uploaded_file(). I felt bad when I saw is_uploaded_file() introduced - it is such a cheezy function call; people shouldn't even have to call it themselves, and I can imagine no situation (except for laziness) that you would not call it. Other ideas? -- ,,, (. .) +--ooO-(_)-Ooo- - -- - - - - | rec.arts.int-fiction archive and research library: | http://bang.dhs.org/if/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
How to get there...
For 4.0.7:
- We leave all default configuration settings as they are now.
- We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
super-globals like $GLOBALS
+1
- We add a new function, somewhat like the current extract() which looks
something like this:
// Another use:
// Only import the given variables from Post or Cookie data.
import_globals(PC,array('user','password','first','last'));
+1
- With the release of 4.0.7 we start hyping this security issue by
linking to a spruced up version of the security chapter in the manual
which describes how exactly to use these new tools.
I'm writing A study in resilience, as a response to the Study in
Scarlet newsletter. A bit late, but it can provide a discussion point.
I'd be happy to see it modified and included in the security chapter.
I like your reasoning for import_globals(). I was wondering if there
was any thought on my earlier proposal, which would be largely a SAPI
change that:
- dies if GET variable is specified while method != GET
- dies if a file in HTTP_POST_FILES fails is_uploaded_file().
This doesn't solve all the items mentioned in the advisory, but it
squishes quite a few!
-Steve
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] crontab support for PHP
Stig S. Bakken ([EMAIL PROTECTED]) wrote: Uhm, why not simply run PHP scripts from cron? Or did you want something inside a web server environment? I personally have been looking for something similar. AOLServer has this facility: http://www.aolserver.com/docs/tcldev/tapi-114.htm and believe me, it rocks. The problem it solves is this: in larger production environments, people have usually figured out how to use CVS to do revision control for what goes up on a web site. cron is one of those annoying things that has to live outside of CVS. In a team where there can be many people on the web server, people DO edit the cron tab, forget to save their changes, and people only discover the problem when something stops working. FWIW, I'm designing a few improvements to the Apache SAPI implementation that might make this improvement. I don't think it belongs in the language itself though. - Steve -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security techniques
Zeev Suraski ([EMAIL PROTECTED]) wrote:
At 12:04 29/07/2001, Stephen van Egmond wrote:
2. when a uploaded file fails is_uploaded_file().
My English parser bailed out on this one :)
How's your PHP parser doing? :)
foreach $f ($HTTP_POST_FILES) {
if (!is_uploaded_file($f)) {
die Ayiee!;
}
}
While it may be rare to find a situation in which it's useful more than
move_uploaded_file(), these cases do exist. I'm not sure what's wrong with
it, can you be more specific?
My feelings upon seeing it were of the aw, man, couldn't something
else check for that?. There isn't any reason you would want to accept
a file that failed is_uploaded_file() -- so why bother even leaving it
as a possibility.
While I'm typing this, I also understand that it may have been an
emergency introduction into the language in response to a vulnerability
report. And I also understand that functionality that exists in some
Server API should, in some way, be reproducible in the core without
duplicating code.
-Steve
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
Zeev Suraski ([EMAIL PROTECTED]) wrote: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and quite easier in case you access them from functions. Having form variables register as global variables is not the 11th commandment, and it's kind of odd to see people treat it as such. It is quite the handy feature, and it will be a bummer to see it go. - E_NOTICE is a runtime issue, one which you would have to check under all possible paths in your logic. That's why leaving security stuff to runtime is always never a good idea. Setting register_globals to off gives you development-time security. I must point out that if we're referring to existing code bases, E_NOTICE and register_globals=off require as much work: all code paths have to be exercised to catch all the old-style idioms. I was trying to step back a bit and identify some of the patterns in the attacks identified in the paper. One extremely popular pattern was spoofing variables by overwriting them: GET variables overwriting POST, usually, and I suggested that some SAPI stunt be pulled to catch that. Although this would improve things, it bears noting that: - it deprecates a valid (on Apache) idiom which, at least, Rasmus uses - this only makes it harder to spoof variables, not impossible. But at least that's something. Whatever. The idea hasn't caught on. I recognize it probably wasn't worthy. -Steve -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [emile@iris-advies.com: Re: [PHP-DEV] Adding URI Translation Handlers]
Back when the mailing lists were down, I started a discussion about adding a feature to PHP to do URI translating. The brief definition of URI translation is that you get to rewrite URIs dynamically. This is how you you would host, for instance, 10,000 florist home pages: http://florists.ftd.com/rosebowlfloral/ and http://florists.ftd.com/fiveflower/ without having 10,000 directoriies under the server root. In Apache, these would be rewritten to a directory containing the style of page the florist chose, with some extra apache notes to tell you which florist page had been visited. The question I wanted to raise was how to do this. And although it looks like initially a simple task, it generalizes to a few other concepts which Apache + mod_perl has done wonders with. This was the most recent post on the topic, and I wondered if there were other thoughts out there? Failing that, I will probably pursue the approach of building this into the Apache SAPI and letting other web servers follow suit. - Forwarded message from Emiliano [EMAIL PROTECTED] - Date: Thu, 31 May 2001 09:34:00 +0200 (CEST) From: Emiliano [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Adding URI Translation Handlers Stephen van Egmond wrote: One thing which I am bumping into is the need to do URI rewriting, kind of like what mod_perl does. I would like to implement this myself in mod_php, and I'm looking for some advice on the implementation. I considered the following: a) Allowing the automatically prepended file (see php's auto_prepend_file config option) to change $ENV['REQUEST_URI'] before the script is actually executed. This, intuitively, seems clean, but would probably happen too late in the request process (it will have already decided to call the error file). Yep. This would be executed in the response phase, but apache itself would have decided in the translation phase way before that not to handle the request. b) adding a new config directive that... what? defines a file to be read which is supposed to define a function? Is eval'ed? The way I see it you have a couple of options: - Use mod_perl, mod_python, mod_tcl(I think) to script a translation handler. - Write a translation handler in C (we do this with Midgard) - Extend mod_php4 to do what mod_perl et al do so you can write handlers in PHP. Conceptually, this is not too hard, but will definately be more work than the other two. You set up the zend engine just like the response phase handler does, set a few relevant variables before you start it (like $ENV['REQUEST_URI'] for example, kick off the script (either be just executing the code, or calling a function therein), then read the relevant variables after the script exits and act on them. You'll be doing this in C. Emile - End forwarded message - -- ,,, (. .) +--ooO-(_)-Ooo- - -- - - - - | The Annotated BeBook: http://bang.dhs.org/be/bebook/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Adding URI Translation Handlers
Brian Moon ([EMAIL PROTECTED]) wrote: I am still not clear on your problem with the rewriting. I don't see what the number of files in the templates has to do with anything. Can you elaborate more on that. Maybe some examples of what the request would be and how you would rewrite it and why. Consider, for example, sourceforge. http://sourceforge.net/projects/myproject/index.html http://sourceforge.net/projects/myproject/bug-list.html http://sourceforge.net/projects/myproject/bug-add.html There are zillions of myprojects, with new ones coming on at the rate of at least several per day. These are all pages which, in the URI - filename translation step of Apache, need to get pointed at some canonical project template directory. Doing this with one rewrite, as you did with articles and pathinfo, doesn't seem sufficient, since there are in fact several files under each directory rather than just one. /articles/65902.html probably gets rewritten to /articles.php which has to go looking through pathinfo. Fine, it works. But I don't think pathinfo is up to the task above. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: 4.0.5: Merge Request
John Donagher ([EMAIL PROTECTED]) wrote: Someone mentioned the idea of bug-squashing parties; I think that's a great idea, although since the project's developers are all over the world it may be a little tricky to organize (I'm not fixing bugs at 10AM). Debian's bug parties are weekend-long affairs. Start Friday, end Monday morning. But I'm really not in favor of adding more process. It's more of a social process than an explicit development process. The only extra process is a new severity level in their bug system, to indicate that bug must be resolved for release to occur. It's not zero-defects, it's zero release-critical defects. People just yell bug party! maybe invite some friends over and start hacking. Everyone in an IRC channel. Personally, I've never seen adding steps to a development process actually help development. It seems like instead of voting, maybe QA people (as well as developers) should have ability to set priorities on bugs (although these are arguably very subject to perspective). The mozilla project allows members of the public to vote for a bug to indicate that it's bad and annoying to them. This can be used as input to determining that a bug is RC. Along other lines, we could play platform favourites and say that anything that reproducibly crashes an x86, ppc, or alpha system is RC. It's all squishy heuristics, and until we start playing with it we'll never know what works. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.5: Merge Request
Andi Gutmans ([EMAIL PROTECTED]) wrote: For the QA guys it might be nice to be able to flag certain bugs in the bug database and then automatically create a summary page which could be sent to php-dev. However, I think it would take too much time to get started. Maybe just manually creating a list with a one line description of bug #, where the bug is and a short short summary would be best. This could be sent to php-dev. Is adding a severity to the bugdb that hard, or is reporting that fiddly? Actually, could the people who maintain the bugdb get in touch with me offline at [EMAIL PROTECTED]? (Please take php-dev out of the subject so it doesn't just show up in my php-dev folder)? I have some ideas. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.5: Merge Request
Andi Gutmans ([EMAIL PROTECTED]) wrote: features (also because it has enough additional features already which are enough for another minor version), but the developers need to actually go through the bugs database and work on those crash bugs. It's not that easy to get everyone to work on them. The Debian project uses a practice which may be useful. Bugs are identified by project leaders as release-critical. Release-critical is a bug severity level which bugs (crashers, cosmetic, whatever) can get promoted to. There's a page giving stats on RC bugs: http://master.debian.org/~wakkerma/bugs/ And approximately monthly bug squashing parties held on IRC: http://lwn.net/2001/0222/a/db-bugsquash.php3 My suggestion, having watched a few open-source projects structured similarly to PHP, is to declare a particular date as a freeze date, with pressure NOT to commit major overhauls increasing as the freeze approached. At the freeze, a CVS branch is created and the bug squashing party begins - release critical bugs only! Once RC bugs get cleared, the branch changes get merged back into the mainline and development resumes until it's time to release again. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] further notes on bug squashing parties
Looking at the RC bugs graph: http://master.debian.org/~wakkerma/bugs/ you'll see two precipitous drops in the number of RC bugs. Those are bug parties. - Steve -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] timezones and thread safety
James L. Pine ([EMAIL PROTECTED]) wrote: I'm running php as an apache 1.x module, so I just hacked in a userspace tzset(TZ) function, but this would be bad for systems that need to play nicely with threads. I'm a little bit baffled about why you would want to change the time zone while a system is up and running. Isn't this the kind of thing you set and forget? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] write access to Zend
I have some patches for Zend (TSRM, in particular, to get threads running on the BeOS). I already have a CVS account for php.net, but it's not valid for Zend. What am I missing? Should I just post them? -- ,,, (. .) +--ooO-(_)-Ooo --- -- - - - - | Stephen van Egmond http://bang.dhs.org/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Dear Friends Future Millionaire:
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
What we are not interested in is stopping people who are not subscribed to
the lists directly from participating. A lot of people read the lists via
nntp or through various web gateways. You can rant all you want about the
spam, but until you come up with a workable way to not cut off these
people there isn't much point.
Understandable.
Listar (the one I'm familiar) will send posts that aren't classified as
spam, but still from non-members, to moderators. Depending on your
mailer, one keypress ("bounce this to [EMAIL PROTECTED]")
will approve the post and send it out. This can be tweaked to
auto-approve future posts from that person.
/Steve
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Did anyone apply that BeOS patch?
I'm not seeing it in current CVS. Could someone confirm that they applied it? Are there any objections? -- ,,, (. .) +--ooO-(_)-Ooo --- -- - - - - | Stephen van Egmond http://bang.dhs.org/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] patch for current CVS to build on BeOS
Attached is the diffs to current CVS to enable PHP4 to build under the
BeOS. Tested with BeOS r5.0.3 under Intel architecture.
The BeOS release currently requires "--without-mysql" due to
differences in the networking stack which are currently being addressed
by Be.
Index: configure.in
===
RCS file: /repository/php4/configure.in,v
retrieving revision 1.211
diff -u -u -r1.211 configure.in
--- configure.in2001/01/14 16:36:29 1.211
+++ configure.in2001/01/14 22:44:54
@@ -106,6 +106,8 @@
CPPFLAGS="$CPPFLAGS -traditional-cpp";;
*bsdi*)
BSD_MAKEFILE=yes;;
+*beos*)
+ LIBS="$LIBS -lbe -lroot"
esac
AM_PROG_CC_STDC
@@ -294,6 +296,7 @@
stdlib.h \
string.h \
syslog.h \
+sysexits.h \
sys/file.h \
sys/mman.h \
sys/resource.h \
@@ -301,6 +304,7 @@
sys/socket.h \
sys/statfs.h \
sys/statvfs.h \
+sys/sysexits.h \
sys/time.h \
sys/types.h \
sys/varargs.h \
@@ -360,6 +364,8 @@
gcvt \
getlogin \
gethostbyaddr \
+getprotobyname \
+getprotobynumber \
getrusage \
gettimeofday \
gmtime_r \
Index: ext/mysql/libmysql/libmysql.c
===
RCS file: /repository/php4/ext/mysql/libmysql/libmysql.c,v
retrieving revision 1.5
diff -u -u -r1.5 libmysql.c
--- ext/mysql/libmysql/libmysql.c 2000/10/20 22:26:48 1.5
+++ ext/mysql/libmysql/libmysql.c 2001/01/14 22:44:54
@@ -25,7 +25,9 @@
#if !defined(MSDOS) !defined(__WIN__)
#include sys/socket.h
#include netinet/in.h
+#ifdef HAVE_ARPA_INET_H
#include arpa/inet.h
+#endif
#include netdb.h
#ifdef HAVE_SELECT_H
# include select.h
Index: ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.297
diff -u -u -r1.297 basic_functions.c
--- ext/standard/basic_functions.c 2001/01/14 16:36:30 1.297
+++ ext/standard/basic_functions.c 2001/01/14 22:44:59
@@ -34,7 +34,9 @@
#include time.h
#include stdio.h
#include netdb.h
+#ifdef HAVE_ARPA_INET_H
#include arpa/inet.h
+#endif
#if HAVE_UNISTD_H
#include unistd.h
#endif
@@ -228,13 +230,19 @@
PHP_FE(mt_srand,
NULL)
PHP_FE(mt_getrandmax, NULL)
PHP_FE(getservbyname, NULL)
+#ifdef HAVE_GETSERVBYPORT
PHP_FE(getservbyport, NULL)
+#endif
+#ifdef HAVE_GETPROTOBYNAME
PHP_FE(getprotobyname, NULL)
+#endif
+#ifdef HAVE_GETPROTOBYNUMBER
PHP_FE(getprotobynumber, NULL)
+#endif
PHP_FE(gethostbyaddr, NULL)
PHP_FE(gethostbyname, NULL)
PHP_FE(gethostbynamel, NULL)
-#if !defined(PHP_WIN32)||HAVE_BINDLIB
+#if HAVE_BINDLIB !(defined(__BEOS__)||defined(PHP_WIN32))
PHP_FE(checkdnsrr,
NULL)
PHP_FE(getmxrr,
second_and_third_args_force_ref)
#else
@@ -424,7 +432,7 @@
PHP_FALIAS(socket_set_timeout, warn_not_available, NULL)
#endif
PHP_FE(socket_get_status, NULL)
-#if !defined(PHP_WIN32) || defined(ZTS)
+#if (!defined(PHP_WIN32) !defined(__BEOS__)) || defined(ZTS)
PHP_FE(realpath,NULL)
#else
PHP_FALIAS(realpath,warn_not_available, NULL)
@@ -2187,8 +2195,8 @@
RETURN_LONG(ntohs(serv-s_port));
}
/* }}} */
-
+#ifdef HAVE_GETSERVBYPORT
/* {{{ proto string getservbyport(int port, string protocol)
Returns service name associated with port. Protocol must be "tcp" or "udp". */
PHP_FUNCTION(getservbyport)
@@ -2210,8 +2218,9 @@
RETURN_STRING(serv-s_name,1);
}
/* }}} */
-
+#endif
+#ifdef HAVE_GETPROTOBYNAME
/* {{{ proto int getprotobyname(string name)
Returns protocol number associated with name as per /etc/protocols */
PHP_FUNCTION(getprotobyname)
@@ -2236,8 +2245,9 @@
RETURN_LONG(ent-p_proto);
}
/* }}} */
-
+#endif
+#ifdef HAVE_GETPROTOBYNUMBER
/* {{{ proto string getprotobynumber(int proto)
Returns protocol name associated with protocol number proto */
PHP_FUNCTION(getprotobynumber)
@@ -2259,7 +2269,7 @@
RETURN_STRING(ent-p_name,1);
}
/* }}} */
-
+#endif
static int php_add_extension_info(zend_module_entry *module, void *arg)
{
Index: ext/standard/dns.c
===
RCS file: /repository/php4/ext/standard/dns.c,v
retrieving revision 1.23
diff -u -u -r1.23 dns.c
--- ext/standard/dns.c 2000/11/27 13:31:21 1.23
+++ ext/standard/dns.c 2001/01/14 22:44:59
@@ -36,15 +36,21 @@
#include winsock.h
#else
#include netinet/in.h
+#ifdef HAVE_ARPA_INET_H
#include
[PHP-DEV] preferred format for patches?
Hello, I don't have a CVS account but I only have a small number of patches to contribute to the current CVS to help it build under the BeOS. How would you like the patches computed? i.e. what command ought I run to generate them? -- ,,, (. .) +--ooO-(_)-Ooo --- -- - - - - | Stephen van Egmond http://bang.dhs.org/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
