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?

I'm not sure why this specific function would not support streams where all others, like exif_imagetype or getimagesize, do.

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?

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.

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.

> 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).

I am not sure why the security mark was removed on this issue? 

a developer could previously have used this method in a unsafe way due to the need for further validation/sanitization of input before passing it toe the method compared to what the doc previously said.

>  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).

If it was only the lack of mentioning It wouldnt be a issue.

What makes it a minor issue is that it explicitly said the opposite.

"This cannot be an URL."

I removed the security flag as its a fairly common security issue, nothing secret about it here (issues marked as security are hidden on our bug tracker)

Ah okay thanks. I was not sure how the security mark worked