You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2014/09/12 01:46:13 UTC
[Bug 56971] New: Serving ArcGIS TIF images results in Internal
Server Error
https://issues.apache.org/bugzilla/show_bug.cgi?id=56971
Bug ID: 56971
Summary: Serving ArcGIS TIF images results in Internal Server
Error
Product: Apache httpd-2
Version: 2.2.25
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: All
Assignee: bugs@httpd.apache.org
Reporter: ian.scott-fleming@ttu.edu
Created attachment 32005
--> https://issues.apache.org/bugzilla/attachment.cgi?id=32005&action=edit
one of many ArcGIS TIFs that result in Internal Server Error
ArcGIS TIF images created by ArcGIS 10.2 results in "Internal Server Error
The server encountered an internal error or misconfiguration and was unable to
complete your request."
(No error code given in resulting response)
Running apache web server 2.2.25 on Centos 6.4. Version 2.2.25 is latest
version available via yum on either Centos or RedHat Enterprise. Our httpd
configuration is essentially standard, except that we force all traffic through
https, using digest authentication to verify users before allowing access
beyond main page.
(Note: Issue is not "critical" for us; workaround was to create tarball with
all images, and have collaborators download tarball for viewing in their own
copy of ArcGIS. However, would be preferable to be able to provide individual
images without collaborators getting "Internal Server Error". Updating to
"latest" apache httpd is not desirable because we try to keep our Centos system
identical with RHEL systems, and updating RHEL systems with later versions of
software than RedHat supports causes problems with their support team.)
Web server has no problem with TIFs from other sources, or with the same images
written from ArcGIS as PNG format.
Attempt to download file via right-click & Save Link As results in a text file
containing the same error message.
TIFs are apparently not standard TIFs -- they cannot be viewed properly in any
image viewer I have tried (irfanview, Mac Preview, Adobe Photoshop...) They
either are reported as corrupt or display as garbage. However, they are
readable by ArcGIS, and display properly in ArcGIS, and the EXIF header
information appears valid.
I believe Esri (providers of ArcGIS) are using the TIFF header format (
0x49492a...) and general TIF framework, but adding some proprietary additional
information.
Underlying problem may be that httpd sees file format as an image format, but
incorrect formatting causes problems. However, apache should do something a
little less catastrophic than "Internal Server Error" when provided with badly
formatted image data.
Contact with Esri support resulted in: " I spoke with a server analyst and
unfortunately we cannot support this particular issue as you hosting image
files on your own Apache Web Sever. "
Looking in the logs: (some directory information replaced w/ xxxxx for
security)
ssl_error_log reports:
[Thu Sep 11 18:00:55 2014] [error] [client 75.16.167.245] Syntax error in type
map, no ':' in
/home/xxxxx/public_html/bioclim/cmip5/GeoTIF/10.year.averages/bioclim1.AnnMeanTemp/CCSM4.r6i1p1.rcp45.SouthWest.1950s.bioclim.var.1.tif
for header ii*, referer:
https://temagami.ttu.edu/~khayhoe/bioclim/cmip5/GeoTIF/10.year.averages/bioclim1.AnnMeanTemp/
ssl_access_log reports:
ssl_access_log:75.16.167.245 - zzzzz [11/Sep/2014:18:00:55 -0500] "GET
/xxxxx/bioclim/cmip5/GeoTIF/10.year.averages/bioclim1.AnnMeanTemp/CCSM4.r6i1p1.rcp45.SouthWest.1950s.bioclim.var.1.tif
HTTP/1.1" 401 468
ssl_access_log:75.16.167.245 - zzzzz [11/Sep/2014:18:00:55 -0500] "GET
/xxxxx/bioclim/cmip5/GeoTIF/10.year.averages/bioclim1.AnnMeanTemp/CCSM4.r6i1p1.rcp45.SouthWest.1950s.bioclim.var.1.tif
HTTP/1.1" 500 601
ssl_request_log reports:
ssl_request_log:[11/Sep/2014:17:53:35 -0500] 75.16.167.245 TLSv1.2
DHE-RSA-AES128-SHA "GET
/xxxxx/bioclim/cmip5/GeoTIF/10.year.averages/bioclim1.AnnMeanTemp/CCSM4.r6i1p1.rcp45.SouthWest.1950s.bioclim.var.1.tif
HTTP/1.1" 601
ssl_request_log:[11/Sep/2014:18:00:55 -0500] 75.16.167.245 TLSv1.2
DHE-RSA-AES128-SHA "GET
/xxxxx/bioclim/cmip5/GeoTIF/10.year.averages/bioclim1.AnnMeanTemp/CCSM4.r6i1p1.rcp45.SouthWest.1950s.bioclim.var.1.tif
HTTP/1.1" 468
Am attaching ArcGIS TIF which causes the error.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56971] Serving ArcGIS TIF images results in Internal Server
Error
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56971
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Eric Covener <co...@gmail.com> ---
It's just the ".var" in the filename, right? You should turn off negotiation /
or remove the AddHandler/SetHandler in your configuration in such directories
if you're not using it
http://httpd.apache.org/docs/2.2/mod/mod_negotiation.html#typemaps
http://httpd.apache.org/docs/2.2/content-negotiation.html
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56971] Serving ArcGIS TIF images results in Internal Server
Error
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56971
--- Comment #2 from ian.scott-fleming@ttu.edu ---
Indeed, that does seem to be the issue. Renaming the files without ".var." in
the middle of the filename does allow the TIFs to be downloaded.
But the documentation says that the AddHandler is for files with an *EXTENSION"
of .var , not for files with ".var" elsewhere in the filename. Note that the
problem files all have extensions of .tif , not .var .
Interpreting any file with .var elsewhere in the filename would cause problems
for anyone wanting or needing to have ".var" in the filename. (In this case,
the researcher is using ".var.10." in order to identify the images with data
from variable 10 in a table of climate variables being analyzed.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56971] Serving ArcGIS TIF images results in Internal Server
Error
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56971
ian.scott-fleming@ttu.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from ian.scott-fleming@ttu.edu ---
Thanks for your suggestions. Adding
RemoveHandler .var
to the <directory /home/*/public_html> section of httpd.conf appears to solve
the problem.
The need for this is somewhat troubling, as it appears to disable a standard
feature of the apache web server. The "var" handler appears to be a default
for apache httpd, and is defined in the default httpd.conf . The comments in
our httpd.conf state:
# For type maps (negotiated resources):
# (This is enabled by default to allow the Apache "It Worked" page
# to be distributed in multiple languages.)
#
AddHandler type-map var
> All of the extension-based things in httpd consider all dot-separated things as extensions.
This is rather counter-intuitive, as using "." to delimit parts of a filename
or directoryname is common usage for linux users. Httpd's treating all
embedded periods (rather than just the last one) places unexpected restrictions
on filenames for users -- not using a string anywhere in the filename that
matches any filehandlers defined for their web server.
One can hardly expect typical users to read and understand the httpd.conf file
before deciding on filenames for files they want to publish on their web pages.
This results in the type of problem we just encountered.
In our case, there are important reasons for the user to have chosen her
filenames the way she did -- using ".var.10." in the filename identifies the
source of the data, following common file naming conventions used in our field
of research.
Please pardon my grumbles, and many thanks for your assistance.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 56971] Serving ArcGIS TIF images results in Internal Server
Error
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56971
--- Comment #3 from Eric Covener <co...@gmail.com> ---
> But the documentation says that the AddHandler is for files with an
> *EXTENSION" of .var , not for files with ".var" elsewhere in the filename.
> Note that the problem files all have extensions of .tif , not .var .
>
All of the extension-based things in httpd consider all dot-separated things as
extensions.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org