Hey Taggic,
Thank you for the response. You're right in noticing that I uploaded the file into the media root and not the playground namespace. I did that as a test, but have again tested by uploading the file (via the Media Files window) and placing it in the playground namespace. So the file now exists at D:\inetpub\DokuWiki\data\media\playground\6qmry.jpg However this had no affect on the problem.
With your second comment, this time I selected No Link and Original Size. So, no more w=200, and the A HREF should be gone too. Upon inserting with the options noted, this is wiki code is placed in the page.
{{:playground:6qmry.jpg?nolink|}}
And I can see that it is rendering correct HTML after saving and viewing the playground wiki page.
<p>
<img src="/lib/exe/fetch.php/playground%3B6qmry.jpg" class="media" alt="" />
</p>
However the images still do not load. Nor the embedded image within the rendered wiki page, or simply taking the img src value and attempting to view it as http://<server>/lib/exe/fetch.php/playground%3B6qmry.jpg As you can see the filename is URL encoded, but that is still accurate. Trying to replace the %3B with a / simply returns "Not Found".
So, I fired up openssl to see what's going on. Since I have http (tcp 80) shut down on that box (and don't plan on enabling it at this point), I opened up firebug in firefox and grabbed the HTTP request. I did it this way to continue using the existing cookies for my session, since auth is required to get into the wiki...
GET /lib/exe/fetch.php?media=6qmry.jpg HTTP/1.1
Host: <server>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: DOKU_PREFS=list%23thumbs%23aceeditor%23on%23sort%23name; DOKU_PREFS=list%23thumbs%23aceeditor%23on%23sort%23name%23link%231%23align%231%23size
%232; DokuWiki=aiq18oi4gp6mai5tn37ssvl731; PHPSESSID=aiq18oi4gp6mai5tn37ssvl731; FCK_NmSp_acl=aiq18oi4gp6mai5tn37ssvl731; FCK_NmSp=playground; DW7fa06
5a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09
Pragma: no-cache
Cache-Control: no-cache
Once connected to the server with openssl
C:\OpenSSL-Win32\bin>openssl.exe s_client -connect <server>:443
And pasted the request above. The server happily responded as it should..
HTTP/1.1 200 OK
Cache-Control: public, proxy-revalidate, no-transform, max-age=86400
Pragma: public
Content-Length: 55868
Content-Type: image/jpeg
Expires: Thu, 22 Mar 2012 09:56:28 GMT
Last-Modified: Wed, 21 Mar 2012 05:15:26 GMT
Accept-Ranges: bytes
ETag: "1d15ae119ff78c359961f5d6b97d0ed7"
Server: Microsoft-IIS/7.0
X-Powered-By: PHP/5.3.9
Set-Cookie: DW7fa065a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09; path=/; secure; httponly
Content-Disposition: inline; filename="6qmry.jpg";
X-Powered-By: ASP.NET
Date: Wed, 21 Mar 2012 09:56:28 GMT
╪ α ►JFIF....(stuff removed)
So I'm stumped. The browser thinks the image is 0x0 pixels, so I can't see it. But the web appears (only appears, because I don't have a point of reference, yet) to be returning exactly what is asked of it.
I decided to try fuling out I did try copying the 6qmry.jpg file to the root directory, bypassing fetch.php simply requesting the image right from the server. This actually worked. Here is the request sent to the server...
GET /6qmry.jpg HTTP/1.1
Host: <server>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: DOKU_PREFS=list%23thumbs%23aceeditor%23on%23sort%23name; DokuWiki=aiq18oi4gp6mai5tn37ssvl731; PHPSESSID=aiq18oi4gp6mai5tn37ssvl731; FCK_NmSp_a
cl=aiq18oi4gp6mai5tn37ssvl731; FCK_NmSp=playground; DW7fa065a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09
Cache-Control: max-age=0
And the associated reply...
HTTP/1.1 200 OK
Content-Type: image/jpeg
Last-Modified: Wed, 21 Mar 2012 09:58:45 GMT
Accept-Ranges: bytes
ETag: "98ba4434497cd1:0"
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Wed, 21 Mar 2012 10:13:51 GMT
Content-Length: 55868
╪ α ►JFIF....(stuff removed)
Just noting the differences in the responses.. When requesting with fetch.php, additional values are returned in the HTTP header. Specifically these ones.
Cache-Control: public, proxy-revalidate, no-transform, max-age=86400
Pragma: public
Expires: Thu, 22 Mar 2012 09:56:28 GMT
X-Powered-By: PHP/5.3.9
Set-Cookie: DW7fa065a06cb74b536c124cfbe56ac6d3=bmZpbm5zc29u%7C0%7CbWs1MmVyQ0R4UlVFekUvMmdYaERTZz09; path=/; secure; httponly
Content-Disposition: inline; filename="6qmry.jpg";
So I'm not sure if something in the extra responses is causing a problem, or maybe the image is being corrupted in the response from fetch.php, but right now something is broken.
Yay details!!
Wow, I just noticed this. Not sure if it would be problematic. The responses contain one additional difference.
using fetch.php
╪ α ►JFIF....(stuff removed)
but when calling the image directly from the server (https://<server>/6qmry.jpg)...
╪ α ►JFIF....(stuff removed)
There is one extra charachter at the beginning of the line. When checking the validity of the image returned using firebug, it reports this... "The image “https://<server>/lib/exe/fetch.php/playground%3B6qmry.jpg” cannot be displayed because it contains errors."
I bet that's what is broken. I'm beat tired and need to go home. But should be back at work in 6 hours or so.