Bug #51968 [NoF->Opn]: dns_get_record() [function.dns-get-record]: res_nsend() failed
Edit report at https://bugs.php.net/bug.php?id=51968&edit=1
ID: 51968
Updated by: h...@php.net
Reported by:php at hm2k dot org
Summary:dns_get_record() [function.dns-get-record]:
res_nsend() failed
-Status: No Feedback
+Status: Open
Type: Bug
Package:*Network Functions
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
What feedback were you expecting?
Previous Comments:
[2013-02-18 00:34:18] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2011-10-07 11:59:27] b1gag3 at hotmail dot de
using error suppression (@dns_get_record('example.com')) works, even it doesn't
solve the problem...
[2011-09-26 10:04:56] m dot alsemany at gmail dot com
even if I make an Exception
this error come !!
the only way to hide is just close the reporting from php.ini :(
[2010-10-12 13:57:38] boyan at peychev dot net
Hello,
I have this problem too:
Warning: dns_get_record() [function.dns-get-record]: res_nsend() failed in .
Example problematic domains:
dns_get_record('gtvip.com.cn', DNS_NS);
dns_get_record('fztuan.tk', DNS_NS);
dns_get_record('forumgeeks.vv.cc', DNS_NS);
dns_get_record('en91.tk', DNS_NS);
dns_get_record('serverdns.ce.ms', DNS_NS);
PHP Version: 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4
2010
03:25:57)
OS: Debian 5.0.6
Regards,
Boyan Peychev
[2010-06-06 12:32:22] h...@php.net
Not Windows. I was testing on CentOS 4 and 5, but based on Google results, I'd
say it's more common across many Linux based servers.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=51968
--
Edit this bug report at https://bugs.php.net/bug.php?id=51968&edit=1
Bug #52403 [Bgs->Opn]: imagettfbbox/imagettftext "Could not read font" error
Edit report at https://bugs.php.net/bug.php?id=52403&edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext "Could not read font" error -Status: Bogus +Status: Open Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: N Private report: N Previous Comments: [2011-12-22 18:24:41] rpalkowski at cyberitas dot com For what it's worth, I just encountered this exact problem and was also thrown by the ambiguity of the warning message, and was barking up the wrong tree for a while before I stumbled upon testing the validity of the font file itself. There is clearly an actual semantic difference between being able to open, and being able to parse or validate a file. If you don't want to change "Could not read font", then the ambiguity could be resolved by changing the other warning message to "Could not open font". [2010-10-19 21:25:38] h...@php.net The issue is not between open and read. imagettfbbox() says the file cannot be read. is_readable() says the file can be read. This is the issue. "Open" is never mentioned in the error. The wording is poor, you are trying to dismiss it as bogus because you deem it unimportant. You seem to agree that the wording is ambiguous and can be improved, yet you are choosing to ignore it. That is just rude, not polite. Is it too much to ask to improve the wording in the name of clarity? [2010-10-19 20:50:53] paj...@php.net Let me rephrase a last time, I won't change this error at this stage. So keep this report as bogus as there is no bug here. The meaning of open and read are clear. I did not say that reporting issues is not valuable. I love bugs reports. However you also have to consider polite negative replies, with arguments. The gain (trying to replace the words open and read so users can understand the difference between these two actions) is not enough in regard to the hassle that it will introduce from a test point of view. [2010-10-19 20:40:12] h...@php.net To confirm, "could not find/read font" means the file is not readable. "Could not read font" means what? And you don't believe these errors are ambiguous? There is clearly an issue with the error being too ambiguous. The gain would be to improve the end user experience. Or are we to assume that improvements are no longer worth reporting? [2010-10-19 18:29:43] paj...@php.net The error if the file does not exist or cannot be open is "could not find/read font". The error when GD cannot (actually Freetype failed) read the font file is "could not read font", which is perfectly correct. There is no bug here and I won't change this error (will have to change in external GD as well, duplicate tests, etc. for no gain). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=52403 -- Edit this bug report at https://bugs.php.net/bug.php?id=52403&edit=1
Bug #53444 [Bgs->ReO]: get_headers and $http_response_header returns unusable formatting
Edit report at http://bugs.php.net/bug.php?id=53444&edit=1 ID: 53444 Updated by: h...@php.net Reported by:h...@php.net Summary:get_headers and $http_response_header returns unusable formatting -Status: Bogus +Status: Re-Opened Type: Bug Package:Streams related PHP Version:5.3.3 Block user comment: N Private report: N New Comment: The standard bug resolution protocol is to close a bug once both parties agree the issue is resolved, if not, the bug may be reopened until it is resolved. Again, you should address this issue. Re-opened. Previous Comments: [2010-12-13 12:43:18] ahar...@php.net I'm pretty sure Ilia intended that as a rhetorical question. hm2k, please don't reopen bugs that have been closed by a core developer just because you disagree with the resolution. It's not the first time you've done it, and to be honest, combined with the constant questioning of whether the triager/assignee is doing the right thing, it's pretty unfriendly. [2010-12-13 12:17:15] h...@php.net Firstly, iliaa you need to learn how to correctly manage bugs. You don't just set them to bogus if you're expecting feedback. I can see that you're expecting feedback as you have asked a question. To answer your question: if you have tried to use these headers for anything useful, you will see that it's impossible to properly distinguish which header is from which request. For example, in the "get_headers format with keys" test, there is absolutely no way to be sure which request returned the values in [Set-Cookie], you can only assume or guess. Another example, with the $http_response_header format, there is no finite way to distinguish one set of responses from another, you can only guess by separating by the status line, however if the headers were poisoned it would render this technique useless. In summary, the formats in which the headers are returned is unusable. The ideal solution would be to separate the headers as they are gathered, giving clear boundaries where one ends and another starts. This should be done natively. [2010-12-12 19:40:42] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php What about the formatting is unusable? In the event of multiple headers the returned values are arrays representing elements of duplicate headers... This is the intended functionality. [2010-12-11 19:40:45] h...@php.net I am aware of the reason I am seeing multiple headers. Multiple headers are what I am expecting. I am aware that the URL is redirecting (as per bug #50719), following redirects is what I am expecting. The issue here is the formatting which is unusable. You should address this issue. [2010-12-11 16:16:27] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The reason you get multiple headers is because the website you are trying to access is redirecting the URL and by default the headers from all requests are being returned. If you don't want redirects to be followed, set the stream context parameter max_redirects to 0. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53444 -- Edit this bug report at http://bugs.php.net/bug.php?id=53444&edit=1
Bug #53444 [Bgs->Fbk]: get_headers and $http_response_header returns unusable formatting
Edit report at http://bugs.php.net/bug.php?id=53444&edit=1
ID: 53444
Updated by: h...@php.net
Reported by:h...@php.net
Summary:get_headers and $http_response_header returns
unusable formatting
-Status: Bogus
+Status: Feedback
Type: Bug
Package:Streams related
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Firstly, iliaa you need to learn how to correctly manage bugs.
You don't just set them to bogus if you're expecting feedback.
I can see that you're expecting feedback as you have asked a question.
To answer your question: if you have tried to use these headers for
anything
useful, you will see that it's impossible to properly distinguish which
header
is from which request.
For example, in the "get_headers format with keys" test, there is
absolutely no
way to be sure which request returned the values in [Set-Cookie], you
can only
assume or guess.
Another example, with the $http_response_header format, there is no
finite way
to distinguish one set of responses from another, you can only guess by
separating by the status line, however if the headers were poisoned it
would
render this technique useless.
In summary, the formats in which the headers are returned is unusable.
The ideal solution would be to separate the headers as they are
gathered, giving
clear boundaries where one ends and another starts. This should be done
natively.
Previous Comments:
[2010-12-12 19:40:42] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
What about the formatting is unusable? In the event of multiple headers
the
returned values are arrays representing elements of duplicate
headers...
This is the intended functionality.
[2010-12-11 19:40:45] h...@php.net
I am aware of the reason I am seeing multiple headers. Multiple headers
are what I
am expecting.
I am aware that the URL is redirecting (as per bug #50719), following
redirects is
what I am expecting.
The issue here is the formatting which is unusable. You should address
this issue.
[2010-12-11 16:16:27] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The reason you get multiple headers is because the website you are
trying to
access is redirecting the URL and by default the headers from all
requests are
being returned. If you don't want redirects to be followed, set the
stream context
parameter max_redirects to 0.
[2010-12-01 23:38:50] h...@php.net
Description:
The get_headers() function and the $http_response_header variable often
returns multiple headers combined into a completely unusable format.
Test script:
---
http://google.com/');
print_r($http_response_header);
echo "Testing the normal get_headers format\n";
$headers=get_headers('http://google.com/');
print_r($headers);
echo "Testing the get_headers format with keys\n";
$headers=get_headers('http://google.com/',1);
print_r($headers);
?>
Expected result:
Each set of headers from each request should be separated into another
array, rather than simply appended to the existing ones.
There is currently no safe way to separate the returned values into a
usable format. The get_headers format with keys is the worst offender of
this.
Actual result:
--
Testing the $http_response_header format
Array
(
[0] => HTTP/1.0 301 Moved Permanently
[1] => Location: http://www.google.com/
[2] => Content-Type: text/html; charset=UTF-8
[3] => Date: Wed, 01 Dec 2010 22:36:17 GMT
[4] => Expires: Fri, 31 Dec 2010 22:36:17 GMT
[5] => Cache-Control: public, max-age=2592000
[6] => Server: gws
[7] => Content-Length: 219
[8] => X-XSS-Protection: 1; mode=block
[9] => HTTP/1.0 302 Found
[10] => Location: http://www.google.co.uk/
[11] => Cache-Control: private
[12] => Content-Type: text/html; charset=UTF-8
[13] => Set-Cookie:
PREF=ID=4a205a8a49c12cc1:FF=0:TM=1291242977:LM=1291242977:S=nhA-vebjo6ayX0bQ;
expires=Fri, 30-Nov-2012 22:36:17 GMT; path=/; domain=.google.com
[14] => Set-Cookie:
NID=41=LcFt9zVP6L3dEVMKDUeNblPFQVRlOJaak9BjEUnZErgDkDh9yjljWhydKUteQdcqGh4PM0gaVJlyLT6CEu6K_LpFYJhRJRMkgy7-u45iMO
Bug #53444 [Bgs->Opn]: get_headers and $http_response_header returns unusable formatting
Edit report at http://bugs.php.net/bug.php?id=53444&edit=1
ID: 53444
Updated by: h...@php.net
Reported by:h...@php.net
Summary:get_headers and $http_response_header returns
unusable formatting
-Status: Bogus
+Status: Open
Type: Bug
Package:Streams related
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
I am aware of the reason I am seeing multiple headers. Multiple headers
are what I
am expecting.
I am aware that the URL is redirecting (as per bug #50719), following
redirects is
what I am expecting.
The issue here is the formatting which is unusable. You should address
this issue.
Previous Comments:
[2010-12-11 16:16:27] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The reason you get multiple headers is because the website you are
trying to
access is redirecting the URL and by default the headers from all
requests are
being returned. If you don't want redirects to be followed, set the
stream context
parameter max_redirects to 0.
[2010-12-01 23:38:50] h...@php.net
Description:
The get_headers() function and the $http_response_header variable often
returns multiple headers combined into a completely unusable format.
Test script:
---
http://google.com/');
print_r($http_response_header);
echo "Testing the normal get_headers format\n";
$headers=get_headers('http://google.com/');
print_r($headers);
echo "Testing the get_headers format with keys\n";
$headers=get_headers('http://google.com/',1);
print_r($headers);
?>
Expected result:
Each set of headers from each request should be separated into another
array, rather than simply appended to the existing ones.
There is currently no safe way to separate the returned values into a
usable format. The get_headers format with keys is the worst offender of
this.
Actual result:
--
Testing the $http_response_header format
Array
(
[0] => HTTP/1.0 301 Moved Permanently
[1] => Location: http://www.google.com/
[2] => Content-Type: text/html; charset=UTF-8
[3] => Date: Wed, 01 Dec 2010 22:36:17 GMT
[4] => Expires: Fri, 31 Dec 2010 22:36:17 GMT
[5] => Cache-Control: public, max-age=2592000
[6] => Server: gws
[7] => Content-Length: 219
[8] => X-XSS-Protection: 1; mode=block
[9] => HTTP/1.0 302 Found
[10] => Location: http://www.google.co.uk/
[11] => Cache-Control: private
[12] => Content-Type: text/html; charset=UTF-8
[13] => Set-Cookie:
PREF=ID=4a205a8a49c12cc1:FF=0:TM=1291242977:LM=1291242977:S=nhA-vebjo6ayX0bQ;
expires=Fri, 30-Nov-2012 22:36:17 GMT; path=/; domain=.google.com
[14] => Set-Cookie:
NID=41=LcFt9zVP6L3dEVMKDUeNblPFQVRlOJaak9BjEUnZErgDkDh9yjljWhydKUteQdcqGh4PM0gaVJlyLT6CEu6K_LpFYJhRJRMkgy7-u45iMOa4xvItP26T_03rqUm-Lrrv;
expires=Thu, 02-Jun-2011 22:36:17 GMT; path=/; domain=.google.com;
HttpOnly
[15] => Date: Wed, 01 Dec 2010 22:36:17 GMT
[16] => Server: gws
[17] => Content-Length: 221
[18] => X-XSS-Protection: 1; mode=block
[19] => HTTP/1.0 200 OK
[20] => Date: Wed, 01 Dec 2010 22:36:17 GMT
[21] => Expires: -1
[22] => Cache-Control: private, max-age=0
[23] => Content-Type: text/html; charset=ISO-8859-1
[24] => Set-Cookie:
PREF=ID=16ffcfbf48f03139:FF=0:TM=1291242977:LM=1291242977:S=Niy-I-NoOBYJK2Tl;
expires=Fri, 30-Nov-2012 22:36:17 GMT; path=/; domain=.google.co.uk
[25] => Set-Cookie:
NID=41=eXX6NtkDo7xtT_Y7l3MVRtVznVjPE0fUUwfcmcSTXOX_80oJhSDTi_NJvidjgq_fwl3xOTvMTXatxlUqJPZsSPk2b8jIZ-oG4_tO9Eyf_beK0jqoJ20u72Ukhsydzxih;
expires=Thu, 02-Jun-2011 22:36:17 GMT; path=/; domain=.google.co.uk;
HttpOnly
[26] => Server: gws
[27] => X-XSS-Protection: 1; mode=block
)
Testing the normal get_headers format
Array
(
[0] => HTTP/1.0 301 Moved Permanently
[1] => Location: http://www.google.com/
[2] => Content-Type: text/html; charset=UTF-8
[3] => Date: Wed, 01 Dec 2010 22:36:17 GMT
[4] => Expires: Fri, 31 Dec 2010 22:36:17 GMT
[5] => Cache-Control: public, max-age=2592000
[6] => Server: gws
[7] => Content-Length: 219
[8] => X-XSS-Protection: 1; mode=block
[9] => HTTP/1.0 302 Found
[10] => Location: http://www.google.co.uk/
[11] => Cache-Control: private
[12] => Content-Type: text/html; charset=UTF-8
[13] => Set-Cookie:
PREF=ID=1c5409426fc05ac7:FF=0:TM=1291242978:LM=1291242978:S=Gq5q1jDdprguyJVX;
expires=Fri, 30-Nov-2012 22:36:18 GMT; path=/; domain=.google.com
[14] => Se
Bug #52404 [Asn->Opn]: All TTF Files are invalid [ALL PHP.NET]
Edit report at http://bugs.php.net/bug.php?id=52404&edit=1 ID: 52404 Updated by: h...@php.net Reported by:h...@php.net Summary:All TTF Files are invalid [ALL PHP.NET] -Status: Assigned +Status: Open Type: Bug Package:*General Issues PHP Version:Irrelevant -Assigned To:rasmus +Assigned To: Block user comment: N Private report: N New Comment: This is not a difficult bug to fix. Anybody with commit access should be able to fix it. Can somebody fix it? Thanks. Previous Comments: [2010-10-18 18:30:24] h...@php.net I would if I could. I don't think I have commit access to all of the ttf files on the php.net svn. [2010-07-27 01:54:48] ras...@php.net You may just have to re-import them into Subversion or something. All I did was flip the svn property so Subversion wouldn't mangle them. [2010-07-27 01:02:53] ka...@php.net Confirmed on Windows XP aswell (unreadable font files in the font viewer) Rasmus: You did this change, should it be reverted or do you have any easy fix on your mind? [2010-07-22 15:13:56] h...@php.net Description: All of the TTF files that are on PHP.net appear to be invalid/corrupt. A change that happened 12 months ago with the description of "Fix TTF files" appears to be where the problem lies. http://svn.php.net/viewvc?view=revision&revision=284292 To fix this, this revision should be reverted to all files. On Windows, when you try to open any of these files it will say "The requested file *.ttf was not a valid font file". Here at PHP, we get a different message when using the imagettfbbox() function... "Could not read font". In the example below I am using the arial.ttf file which can be downloaded here: http://svn.php.net/viewvc/web/php/trunk/bin/arial.ttf?view=co Test script: --- Does font '$font' exist? ".$read; $read = is_readable($font)?'Yes':'No'; echo "\nIs font '$font' readable? ".$read; $test = @imagettfbbox(1, 1, $font, 1)?'Yes':'No'; echo "\nIs font '$font' valid? ".$test; echo "\nWhat PHP version? ".phpversion(); ?> Expected result: Does font 'fonts/arial.ttf' exist? Yes Is font 'fonts/arial.ttf' readable? Yes Is font 'fonts/arial.ttf' valid? Yes What PHP version? 5.2.13 Actual result: -- Does font 'fonts/arial.ttf' exist? Yes Is font 'fonts/arial.ttf' readable? Yes Is font 'fonts/arial.ttf' valid? No What PHP version? 5.2.13 -- Edit this bug report at http://bugs.php.net/bug.php?id=52404&edit=1
Bug #53375 [Bgs->Opn]: imap_search 'ALL' always returns false
Edit report at http://bugs.php.net/bug.php?id=53375&edit=1 ID: 53375 Updated by: h...@php.net Reported by:h...@php.net Summary:imap_search 'ALL' always returns false -Status: Bogus +Status: Open Type: Bug Package:IMAP related Operating System: CentOS PHP Version:5.3.3 Block user comment: N Private report: N New Comment: The bug is in PHP, it is a PHP implementation of the IMAP c-client library. Reporting the bug in a third party implementations is NOT the responsibility of the end user, it is of the developer. Imagine if I told every user of every bug reported to me in everything I developed in PHP to do the same thing you're telling me. They would get closed and the bug would never get fixed. So, this doesn't wash with me I'm afraid. All that aside, this bug is NOT bogus. I created an implementation in perl which worked fine, while the PHP counterpart fails. The least you should do as a representative for this implementation is report the bug to the appropriate vendor on behalf of the end user. I trust you will agree. Previous Comments: [2010-11-25 20:51:54] il...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Looking at the backend code, PHP calls the mail_search_full() method directly and relies on its output, so the issue lies within c-client, rather than PHP. [2010-11-22 12:58:44] h...@php.net Further more, here's an example of it working by sending raw commands to the imap server through a normal telnet connection. --- * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THRE AD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyr ight 1998-2010 Double Precision, Inc. See COPYING for distribution information. a1 LOGIN OK LOGIN Ok. a2 EXAMINE INBOX* FLAGS ($MDNSent Junk NonJunk $Forwarded \Draft \Answered \Flag ged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS ()] No permanent flags permitted * 984 EXISTS * 0 RECENT * OK [UIDVALIDITY 1174303484] Ok * OK [MYRIGHTS "acdilrsw"] ACL a2 OK [READ-ONLY] Ok a3 SEARCH ALL* SEARCH 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 2 3 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 10 2 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 12 2 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 14 2 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 16 2 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 18 2 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 20 2 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 22 2 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 24 2 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 26 2 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 28 2 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 30 2 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 32 2 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 34 2 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 36 2 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 38 2 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 40 2 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 42 2 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 44 2 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 46 2 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 48 2 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 50 2 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 52 2 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 54 2 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 56 2 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581
Bug #52403 [Bgs]: imagettfbbox/imagettftext "Could not read font" error
Edit report at http://bugs.php.net/bug.php?id=52403&edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext "Could not read font" error Status: Bogus Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: N New Comment: The issue is not between open and read. imagettfbbox() says the file cannot be read. is_readable() says the file can be read. This is the issue. "Open" is never mentioned in the error. The wording is poor, you are trying to dismiss it as bogus because you deem it unimportant. You seem to agree that the wording is ambiguous and can be improved, yet you are choosing to ignore it. That is just rude, not polite. Is it too much to ask to improve the wording in the name of clarity? Previous Comments: [2010-10-19 20:50:53] paj...@php.net Let me rephrase a last time, I won't change this error at this stage. So keep this report as bogus as there is no bug here. The meaning of open and read are clear. I did not say that reporting issues is not valuable. I love bugs reports. However you also have to consider polite negative replies, with arguments. The gain (trying to replace the words open and read so users can understand the difference between these two actions) is not enough in regard to the hassle that it will introduce from a test point of view. [2010-10-19 20:40:12] h...@php.net To confirm, "could not find/read font" means the file is not readable. "Could not read font" means what? And you don't believe these errors are ambiguous? There is clearly an issue with the error being too ambiguous. The gain would be to improve the end user experience. Or are we to assume that improvements are no longer worth reporting? [2010-10-19 18:29:43] paj...@php.net The error if the file does not exist or cannot be open is "could not find/read font". The error when GD cannot (actually Freetype failed) read the font file is "could not read font", which is perfectly correct. There is no bug here and I won't change this error (will have to change in external GD as well, duplicate tests, etc. for no gain). [2010-10-18 22:20:55] h...@php.net No, the message is ambiguous. Consider this... If GD is able to read the file, it is readable. If GD is unable to read the file, it is unreadable. We know the file is readable, that is not the problem. If GD is able to validate the file, it is valid. If GD is unable to validate the file, it is invalid. We do not know whether the file is valid or not. Alternatively, If GD is able to support the file, it is supported. If GD is unable to support the file, it is unsupported. We do not know whether the file is supported or not. To use "read" is too ambiguous in this context. [2010-10-18 20:29:04] paj...@php.net The message is correct. As some fonts are supported by some freetype versions. It does not mean that the font file is invalid, but that ft (gd) could not read it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52403 -- Edit this bug report at http://bugs.php.net/bug.php?id=52403&edit=1
Bug #52403 [Bgs->Opn]: imagettfbbox/imagettftext "Could not read font" error
Edit report at http://bugs.php.net/bug.php?id=52403&edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext "Could not read font" error -Status: Bogus +Status: Open Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: N New Comment: To confirm, "could not find/read font" means the file is not readable. "Could not read font" means what? And you don't believe these errors are ambiguous? There is clearly an issue with the error being too ambiguous. The gain would be to improve the end user experience. Or are we to assume that improvements are no longer worth reporting? Previous Comments: [2010-10-19 18:29:43] paj...@php.net The error if the file does not exist or cannot be open is "could not find/read font". The error when GD cannot (actually Freetype failed) read the font file is "could not read font", which is perfectly correct. There is no bug here and I won't change this error (will have to change in external GD as well, duplicate tests, etc. for no gain). [2010-10-18 22:20:55] h...@php.net No, the message is ambiguous. Consider this... If GD is able to read the file, it is readable. If GD is unable to read the file, it is unreadable. We know the file is readable, that is not the problem. If GD is able to validate the file, it is valid. If GD is unable to validate the file, it is invalid. We do not know whether the file is valid or not. Alternatively, If GD is able to support the file, it is supported. If GD is unable to support the file, it is unsupported. We do not know whether the file is supported or not. To use "read" is too ambiguous in this context. [2010-10-18 20:29:04] paj...@php.net The message is correct. As some fonts are supported by some freetype versions. It does not mean that the font file is invalid, but that ft (gd) could not read it. [2010-10-18 18:32:39] h...@php.net To put it very simply, it incorrectly says "Could not read font", when it should say "Invalid font file". Could somebody fix this or do you need me to supply a patch? [2010-07-27 14:56:55] h...@php.net To clarify: Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Invalid font file in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52403 -- Edit this bug report at http://bugs.php.net/bug.php?id=52403&edit=1
Bug #52403 [Bgs->Opn]: imagettfbbox/imagettftext "Could not read font" error
Edit report at http://bugs.php.net/bug.php?id=52403&edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext "Could not read font" error -Status: Bogus +Status: Open Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: N Previous Comments: [2010-10-18 22:20:55] h...@php.net No, the message is ambiguous. Consider this... If GD is able to read the file, it is readable. If GD is unable to read the file, it is unreadable. We know the file is readable, that is not the problem. If GD is able to validate the file, it is valid. If GD is unable to validate the file, it is invalid. We do not know whether the file is valid or not. Alternatively, If GD is able to support the file, it is supported. If GD is unable to support the file, it is unsupported. We do not know whether the file is supported or not. To use "read" is too ambiguous in this context. [2010-10-18 20:29:04] paj...@php.net The message is correct. As some fonts are supported by some freetype versions. It does not mean that the font file is invalid, but that ft (gd) could not read it. [2010-10-18 18:32:39] h...@php.net To put it very simply, it incorrectly says "Could not read font", when it should say "Invalid font file". Could somebody fix this or do you need me to supply a patch? [2010-07-27 14:56:55] h...@php.net To clarify: Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Invalid font file in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes [2010-07-27 10:57:18] h...@php.net Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52403 -- Edit this bug report at http://bugs.php.net/bug.php?id=52403&edit=1
Bug #52403 [Bgs]: imagettfbbox/imagettftext "Could not read font" error
Edit report at http://bugs.php.net/bug.php?id=52403&edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext "Could not read font" error Status: Bogus Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: N New Comment: No, the message is ambiguous. Consider this... If GD is able to read the file, it is readable. If GD is unable to read the file, it is unreadable. We know the file is readable, that is not the problem. If GD is able to validate the file, it is valid. If GD is unable to validate the file, it is invalid. We do not know whether the file is valid or not. Alternatively, If GD is able to support the file, it is supported. If GD is unable to support the file, it is unsupported. We do not know whether the file is supported or not. To use "read" is too ambiguous in this context. Previous Comments: [2010-10-18 20:29:04] paj...@php.net The message is correct. As some fonts are supported by some freetype versions. It does not mean that the font file is invalid, but that ft (gd) could not read it. [2010-10-18 18:32:39] h...@php.net To put it very simply, it incorrectly says "Could not read font", when it should say "Invalid font file". Could somebody fix this or do you need me to supply a patch? [2010-07-27 14:56:55] h...@php.net To clarify: Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Invalid font file in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes [2010-07-27 10:57:18] h...@php.net Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. [2010-07-27 01:04:09] ka...@php.net Same issue as in bug #52404 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52403 -- Edit this bug report at http://bugs.php.net/bug.php?id=52403&edit=1
Bug #52403 [Opn]: imagettfbbox/imagettftext "Could not read font" error
Edit report at http://bugs.php.net/bug.php?id=52403&edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext "Could not read font" error Status: Open Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: Y New Comment: To put it very simply, it incorrectly says "Could not read font", when it should say "Invalid font file". Could somebody fix this or do you need me to supply a patch? Previous Comments: [2010-07-27 14:56:55] h...@php.net To clarify: Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Invalid font file in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes [2010-07-27 10:57:18] h...@php.net Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. [2010-07-27 01:04:09] ka...@php.net Same issue as in bug #52404 [2010-07-22 14:24:49] h...@php.net Description: Using the Vera.ttf font, which is part of the Image_Text PEAR package results in an odd error... The font can be found here: http://svn.php.net/viewvc/pear/packages/Image_Text/trunk/tests/Vera.ttf?view=log The error given by imagettfbbox() is "Could not read font". When tested with is_readable(), the font is indeed readable. When opening the Vera.ttf font file in windows, it produces the following error: "The requested file Vera.ttf was not a valid font file." It would appear that the file may well be corrupt, not that it "could not read". This error lead to a very confusing situation... I propose that the error should be more descriptive. Instead of "Could not read font", consider "Invalid font file". Test script: --- What PHP version? ".phpversion(); $read = file_exists($font)?'Yes':'No'; echo "\nDoes font '$font' exist? ".$read; $read = is_readable($font)?'Yes':'No'; echo "\nIs font '$font' readable? ".$read; ?> Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes -- Edit this bug report at http://bugs.php.net/bug.php?id=52403&edit=1
Bug #52404 [Asn]: All TTF Files are invalid [ALL PHP.NET]
Edit report at http://bugs.php.net/bug.php?id=52404&edit=1 ID: 52404 Updated by: h...@php.net Reported by:h...@php.net Summary:All TTF Files are invalid [ALL PHP.NET] Status: Assigned Type: Bug Package:*General Issues PHP Version:Irrelevant Assigned To:rasmus Block user comment: N New Comment: I would if I could. I don't think I have commit access to all of the ttf files on the php.net svn. Previous Comments: [2010-07-27 01:54:48] ras...@php.net You may just have to re-import them into Subversion or something. All I did was flip the svn property so Subversion wouldn't mangle them. [2010-07-27 01:02:53] ka...@php.net Confirmed on Windows XP aswell (unreadable font files in the font viewer) Rasmus: You did this change, should it be reverted or do you have any easy fix on your mind? [2010-07-22 15:13:56] h...@php.net Description: All of the TTF files that are on PHP.net appear to be invalid/corrupt. A change that happened 12 months ago with the description of "Fix TTF files" appears to be where the problem lies. http://svn.php.net/viewvc?view=revision&revision=284292 To fix this, this revision should be reverted to all files. On Windows, when you try to open any of these files it will say "The requested file *.ttf was not a valid font file". Here at PHP, we get a different message when using the imagettfbbox() function... "Could not read font". In the example below I am using the arial.ttf file which can be downloaded here: http://svn.php.net/viewvc/web/php/trunk/bin/arial.ttf?view=co Test script: --- Does font '$font' exist? ".$read; $read = is_readable($font)?'Yes':'No'; echo "\nIs font '$font' readable? ".$read; $test = @imagettfbbox(1, 1, $font, 1)?'Yes':'No'; echo "\nIs font '$font' valid? ".$test; echo "\nWhat PHP version? ".phpversion(); ?> Expected result: Does font 'fonts/arial.ttf' exist? Yes Is font 'fonts/arial.ttf' readable? Yes Is font 'fonts/arial.ttf' valid? Yes What PHP version? 5.2.13 Actual result: -- Does font 'fonts/arial.ttf' exist? Yes Is font 'fonts/arial.ttf' readable? Yes Is font 'fonts/arial.ttf' valid? No What PHP version? 5.2.13 -- Edit this bug report at http://bugs.php.net/bug.php?id=52404&edit=1
Bug #52403 [Dup->Opn]: imagettfbbox/imagettftext "Could not read font" error
Edit report at http://bugs.php.net/bug.php?id=52403&edit=1 ID: 52403 Updated by: h...@php.net Reported by:h...@php.net Summary:imagettfbbox/imagettftext "Could not read font" error -Status: Duplicate +Status: Open Type: Bug Package:GD related Operating System: CentOS4 PHP Version:5.2.13 Block user comment: Y New Comment: Excuse me, but this is -NOT- the same bug. Just because it's simply related does not make it the same. The problem here is the error, not the TTF files, which is the problem described in the other bug report. Please check and try again. Previous Comments: [2010-07-27 01:04:09] ka...@php.net Same issue as in bug #52404 [2010-07-22 14:24:49] h...@php.net Description: Using the Vera.ttf font, which is part of the Image_Text PEAR package results in an odd error... The font can be found here: http://svn.php.net/viewvc/pear/packages/Image_Text/trunk/tests/Vera.ttf?view=log The error given by imagettfbbox() is "Could not read font". When tested with is_readable(), the font is indeed readable. When opening the Vera.ttf font file in windows, it produces the following error: "The requested file Vera.ttf was not a valid font file." It would appear that the file may well be corrupt, not that it "could not read". This error lead to a very confusing situation... I propose that the error should be more descriptive. Instead of "Could not read font", consider "Invalid font file". Test script: --- What PHP version? ".phpversion(); $read = file_exists($font)?'Yes':'No'; echo "\nDoes font '$font' exist? ".$read; $read = is_readable($font)?'Yes':'No'; echo "\nIs font '$font' readable? ".$read; ?> Expected result: Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 Actual result: -- Warning: imagettfbbox() [function.imagettfbbox]: Could not read font in /home/share/www/dev/test/php/imagettfbbox.php on line 4 What PHP version? 5.2.13 Does font 'Vera.ttf' exist? Yes Is font 'Vera.ttf' readable? Yes -- Edit this bug report at http://bugs.php.net/bug.php?id=52403&edit=1
[PHP-BUG] Bug #51968 [NEW]: dns_get_record() [function.dns-get-record]: res_nsend() failed
From: Operating system: PHP version: 5.3.2 Package: *Network Functions Bug Type: Bug Bug description:dns_get_record() [function.dns-get-record]: res_nsend() failed Description: Certain hosts cause the dns_get_record() to fail with the following error: Warning: dns_get_record() [function.dns-get-record]: res_nsend() failed in dns.php on line 3 A live example of this error is found here: http://www.easywhois.com/index.php?mode=dnsinfo&domain=jjpny.com Test script: --- -- Edit bug report at http://bugs.php.net/bug.php?id=51968&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51968&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51968&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51968&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51968&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51968&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51968&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51968&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51968&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51968&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51968&r=support Expected behavior: http://bugs.php.net/fix.php?id=51968&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51968&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51968&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51968&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51968&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51968&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51968&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51968&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51968&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51968&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51968&r=mysqlcfg
#50719 [NEW]: get_headers and file_get_contents always follows location redirect
From: php at hm2k dot org
Operating system:
PHP version: 5.3.1
PHP Bug Type: Streams related
Bug description: get_headers and file_get_contents always follows location
redirect
Description:
get_headers and file_get_contents should not blindly follow the location
redirect.
The reason for this is that I, like others, want to get_headers of the
url i've supplied, not the ultimate location.
I'm not the only one having this issue, also see:
http://www.php.net/manual/en/function.get-headers.php#90434
Reproduce code:
---
$headers=get_headers('http://tinyurl.com/hm2k');
Expected result:
echo $headers['Location']; //returns
http://connecting.nokia.com/NOKIA/WWW/HRJEdisc.nsf/HNew/0CB2705072779CACC2256D630080E7F4
Actual result:
--
Warning: get_headers(http://tinyurl.com/hm2k) [function.get-headers]:
failed to open stream: Connection timed out
--
Edit bug report at http://bugs.php.net/?id=50719&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50719&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50719&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50719&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50719&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50719&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50719&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50719&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50719&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50719&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50719&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50719&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50719&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50719&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50719&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50719&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50719&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50719&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50719&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50719&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50719&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50719&r=mysqlcfg
#43402 [NoF]: FILTER_VALIDATE_EMAIL is not RFC2822 compliant
ID: 43402 Updated by: h...@php.net Reported By: nobody at example dot org Status: No Feedback Bug Type: Feature/Change Request Operating System: * PHP Version: 5.2.5 New Comment: Please review this article with regards to this issue -> http://www.hm2k.com/posts/what-is-a-valid-email-address Previous Comments: [2009-11-10 21:55:25] adminekb at mail dot ru And what about this bug? Can anyone fix it? [2009-10-06 07:27:42] hickseydr at optusnet dot com dot au pajoye: this is just a heads up that Dominic Sayer's is_email code at http://code.google.com/p/isemail/source/browse/trunk/is_email.php is now licensed under a BSD license. [2009-04-28 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-04-20 14:43:21] paj...@php.net hi, We can't include GPL code. Is it possible to provide them under BSD? [2009-04-20 14:29:58] dominic dot sayers at gmail dot com The 228 test cases I collated might help determine which approach to follow in resolving this. They can also be found at http://www.dominicsayers.com/isemail Both the test cases and the validation code are now GPL licensed at Damien's request. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43402 -- Edit this bug report at http://bugs.php.net/?id=43402&edit=1
#50347 [Bgs]: $http_response_header does not get populated by file_put_contents stream
ID: 50347
User updated by: php at hm2k dot org
Reported By: php at hm2k dot org
Status: Bogus
Bug Type:Streams related
PHP Version: 5.3.1
New Comment:
Ah, touché, I need to open the stream first.
Previous Comments:
[2009-12-01 08:47:09] j...@php.net
Well, your script only writes 'http://example.com' string to the
$file.
RTFM: http://php.net/file_put_contents
[2009-12-01 08:43:59] php at hm2k dot org
Your question is already answered by the sample code I provided.
For clarification: file_put_contents() is reading from a URL and
writing to a temp file.
[2009-12-01 08:35:54] j...@php.net
What exactly are you trying to do? Write to HTTP?
[2009-12-01 00:56:24] php at hm2k dot org
Description:
When using file_put_contents(), $http_response_header does not populate
as expected.
Reproduce code:
---
http://example.com/';
file_put_contents($file,$url);
var_dump($http_response_header);
Expected result:
array(9) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Sat, 12 Apr 2008 17:30:38 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(44) "Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT"
[4]=>
string(27) "ETag: "280100-1b6-80bfd280""
[5]=>
string(20) "Accept-Ranges: bytes"
[6]=>
string(19) "Content-Length: 438"
[7]=>
string(17) "Connection: close"
[8]=>
string(38) "Content-Type: text/html; charset=UTF-8"
}
Actual result:
--
false
--
Edit this bug report at http://bugs.php.net/?id=50347&edit=1
#50347 [Fbk->Opn]: $http_response_header does not get populated by file_put_contents stream
ID: 50347
User updated by: php at hm2k dot org
Reported By: php at hm2k dot org
-Status: Feedback
+Status: Open
Bug Type:Streams related
PHP Version: 5.3.1
New Comment:
Your question is already answered by the sample code I provided.
For clarification: file_put_contents() is reading from a URL and
writing to a temp file.
Previous Comments:
[2009-12-01 08:35:54] j...@php.net
What exactly are you trying to do? Write to HTTP?
[2009-12-01 00:56:24] php at hm2k dot org
Description:
When using file_put_contents(), $http_response_header does not populate
as expected.
Reproduce code:
---
http://example.com/';
file_put_contents($file,$url);
var_dump($http_response_header);
Expected result:
array(9) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Sat, 12 Apr 2008 17:30:38 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(44) "Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT"
[4]=>
string(27) "ETag: "280100-1b6-80bfd280""
[5]=>
string(20) "Accept-Ranges: bytes"
[6]=>
string(19) "Content-Length: 438"
[7]=>
string(17) "Connection: close"
[8]=>
string(38) "Content-Type: text/html; charset=UTF-8"
}
Actual result:
--
false
--
Edit this bug report at http://bugs.php.net/?id=50347&edit=1
#50347 [NEW]: $http_response_header does not get populated by file_put_contents stream
From: php at hm2k dot org
Operating system:
PHP version: 5.3.1
PHP Bug Type: Streams related
Bug description: $http_response_header does not get populated by
file_put_contents stream
Description:
When using file_put_contents(), $http_response_header does not populate as
expected.
Reproduce code:
---
http://example.com/';
file_put_contents($file,$url);
var_dump($http_response_header);
Expected result:
array(9) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Sat, 12 Apr 2008 17:30:38 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(44) "Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT"
[4]=>
string(27) "ETag: "280100-1b6-80bfd280""
[5]=>
string(20) "Accept-Ranges: bytes"
[6]=>
string(19) "Content-Length: 438"
[7]=>
string(17) "Connection: close"
[8]=>
string(38) "Content-Type: text/html; charset=UTF-8"
}
Actual result:
--
false
--
Edit bug report at http://bugs.php.net/?id=50347&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50347&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50347&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50347&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50347&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50347&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50347&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50347&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50347&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50347&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50347&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50347&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50347&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50347&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50347&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50347&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50347&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50347&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50347&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50347&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50347&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50347&r=mysqlcfg
#5311 [Com]: implement checkdnsrr() and getmxrr() on windows
ID: 5311
Comment by: php at hm2k dot org
Reported By: steve at tradinglinx dot com
Status: To be documented
Bug Type: Feature/Change Request
Operating System: W2000
PHP Version: 4.0.1
New Comment:
I love the fact that I was just writing about this as it was updated:
http://www.hm2k.com/posts/php-getmxrr-support-for-windows
*grin*
Previous Comments:
[2009-01-06 21:50:30] paj...@php.net
> tbd
[2009-01-06 20:52:36] paj...@php.net
As a new year present, all DNS functions are now available on windows,
5.3 and 6 (head).
Waiting my extra slice of cakes.
[2003-01-28 18:28:49] poll...@php.net
Windows users can get this functionality from the PEAR class Net_DNS.
http://pear.php.net/net_dns
[2001-02-24 13:47:02] jmo...@php.net
Both of these are #Defined out in the source code.. someone needs too
look for a win32 implmentation of these at some point (dns.c:170 #if
HAVE_BINDLIB && !(defined(__BEOS__)||defined(PHP_WIN32))).
Changing to Feature Change Request.
[2000-08-12 13:50:49] waldschr...@php.net
user comment:
Neither checkdnsrr nor getmxrr appear work under Windows NT
4/SP6a with IIS
4.
I'm running with the downloaded Windows binary 4.0.1pl2 and
the provided
.ini file. OS is NT 4.0/sp6a, IIS 4.
Under Windows, checkdnsrr always returns "true" (no matter
whether the
provided domain name could even possibly be valid) and
getmxrr returns 0
hosts.
(append ?domain=domaintotest.com to the URL when calling
this script)
checkdnsrr:
".(checkdnsrr($domain,"MX")?"true":"false"));
getmxrr($domain,$mxhosts);
echo("getmxrr: [".count($mxhosts)."] ");
for ( $i = 0; $i < count ( $mxhosts ); $i++ ) {
echo($mxhosts[$i]." ");
}
?>
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/5311
--
Edit this bug report at http://bugs.php.net/?id=5311&edit=1
#45996 [Com]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 Comment by: phpbugs at hm2k dot org Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: This problem is also documented here... http://social.microsoft.com/Forums/en-US/writerbeta/thread/62ad697b-ed19-4b0b-ae6a-32bec06b142b/ Previous Comments: [2008-10-25 18:12:57] alykhanii at yahoo dot com This bug has messed up the XMLRPC upload capabilities in Wordpress hopefully a solution is coming soon. [2008-10-24 20:47:08] sanepit at o2 dot pl I have the same problem on Gentoo with new libxml2-2.6.32 In moodle platform this problem disable to restore courses backup. [2008-10-22 11:39:48] markus dot gevers at contenit dot de Hallo, is there a solution yet? I have the same problem on Fedora Core 9. I also have this problem using libxml2-2.6.32 Can anyone help me? Best regards, Markus [2008-10-17 14:08:57] [EMAIL PROTECTED] Changing the flag fixes internally defined entities, but breaks the rest of the entity handling. [2008-10-17 13:40:27] [EMAIL PROTECTED] So far as I can tell the only problem here is that libxml2 is bailing in parser.c:xmlParseReference() because the ctxt->wellFormed flag is cleared. It is set to zero by compat.c, which seems simply wrong; xmlCreate*ParserContext initialize it to non-zero. If I apply this patch it works fine: http://people.apache.org/~jorton/php-5.2.6-xmlwformed.patch Rob? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45996 -- Edit this bug report at http://bugs.php.net/?id=45996&edit=1
