Doc #74634 [Csd]: read_exif_data() documented as not taking URLs but allows URLs
| From: | cmb@php.net | Date: | Tue, 22 Aug 2017 22:13:50 +0000 |
| Subject: | Doc #74634 [Csd]: read_exif_data() documented as not taking URLs but allows URLs | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-14915@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=74634&edit=1
ID: 74634
Updated by: cmb@php.net
Reported by: rskansing at gmail dot com
Summary: read_exif_data() documented as not taking URLs but
allows URLs
Status: Closed
Type: Documentation Problem
Package: Documentation problem
Operating System: Linux
PHP Version: 7.1.5
-Assigned To: cmb
+Assigned To: kalle
Block user comment: N
Private report: N
New Comment:
> It was me who was not entirely good at documenting this behavior
> I implemented in 7.2, [â¦]
Actually, this ticket is not about the new feature that
exif_read_data accepts a stream, but rather about the
long-standing feature that the function accepts not only filenames
(in the strict sense), but also general URL wrappers (such as
http://example.com/foo?bar). The OP claims that the failure
to
explicitly document that the function supports general URL
wrappers, can cause developers to write vulnerable code, which
*might* be the case (I cannot assess that, though).
Previous Comments:
------------------------------------------------------------------------
[2017-08-22 17:12:25] kalle@php.net
It was me who was not entirely good at documenting this behavior I implemented in 7.2, I blame my
long time absence from working with the docs.
The exif extension supports streams like other functions that support streams in PHP do, in the same
way. Any value passed should always be validated like anything else :)
Thanks Christoph for fixing this, didn't see it myself as it was wrongly labeled as a security
issue.
------------------------------------------------------------------------
[2017-08-22 16:45:34] cmb@php.net
FTR: most functions support general stream wrappers if a filename
is expected, and I assume that is not explicitly documented for
many of those.
I have documented that for this particular function in
<http://svn.php.net/viewvc?view=revision&revision=342914>,
but not
for others.
------------------------------------------------------------------------
[2017-07-30 11:58:58] rskansing at gmail dot com
Any update on this issue? Seems straight forward to fix the docs, as it seems to be consistent
behavior across the similar methods as mentioned.
But will it just be fixed silently?
------------------------------------------------------------------------
[2017-06-19 21:37:05] stas@php.net
I'm not sure why this specific function would not support streams where all others, like
exif_imagetype or getimagesize, do.
------------------------------------------------------------------------
[2017-06-08 10:44:11] leigh@php.net
The documentation (http://php.net/exif_read_data) specifically states:
filename
The name of the image file being read. This cannot be an URL.
Looking at the history of exif.c it seems that exif_read_data has always (going back 15+ years)
called exif_read_file, and exif_read_file has always used php_stream_open_wrapper
So which is correct, the documentation or the current behaviour?
------------------------------------------------------------------------
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=74634
--
Edit this bug report at https://bugs.php.net/bug.php?id=74634&edit=1