Description of all mod_gzip status codes
This document describes the set of all status codes created by mod_gzip 1.3.26.1a about its processing and provided via the field description %{mod_gzip_result}n
for usage inside log formats.
DECLINED:UNHANDLED_SUBREQ
originated by |
meaning |
mod_gzip_type_checker |
This is an Apache internal partial request, caused by processing another 'normal' request. Only this normal request's final result will be checked (and possibly compressed) by mod_gzip. |
DECLINED:UNHANDLED_REDIR
originated by |
meaning |
mod_gzip_type_checker |
This is an Apache internal redirection, caused by processing another 'normal' request. Only this normal request's final result will be checked (and possibly compressed) by mod_gzip. |
DECLINED:INIT1
originated by |
meaning |
mod_gzip_type_checker |
This seems to be a value setting as initialization - at least it has no immediate effect on the order of processing. |
DECLINED:STATIC_GZ_FOUND
originated by |
meaning |
mod_gzip_type_checker |
For the requested file a statically compressed version (with the hard-coded filename extension .gz ) was found and could be delivered to the UserAgent, instead of dynamically compressing the original file. |
mod_gzip_handler |
DECLINED:FEXT_GZ
originated by |
meaning |
mod_gzip_type_checker |
The request explicitly refers to a statically compressed file (with the hard-coded filename extension .gz ); the content of such files is delivered without modification. |
mod_gzip_handler |
DECLINED:NO_DCONF
originated by |
meaning |
mod_gzip_type_checker |
The dconf pointer is NULL. mod_gzip cannot find its configuration record and thus has no chance to check the settings of its configuration directives. |
DECLINED:OFF
originated by |
meaning |
mod_gzip_type_checker |
The compression mode has not been enabled for this file's definition scope (mod_gzip_on No for the complete Apache configuration, this virtual host, this directory or this .htaccess file) |
DECLINED:NOT_GET_OR_POST
originated by |
meaning |
mod_gzip_type_checker |
This request doesn't use one of the HTTP methods GET or POST , but only these method's data can be reasonably compressed. |
DECLINED:HEAD_REQUEST
originated by |
meaning |
mod_gzip_type_checker |
This request uses the HTTP method HEAD ; such a request doesn't cause the creation of a (compressable) document content but only the creation of a (uncompressable) HTTP headers. |
DECLINED:HTTP_LEVEL_TOO_LOW
originated by |
meaning |
mod_gzip_type_checker |
This request uses a HTTP protocol version not as high as at least required by the directive mod_gzip_min_http . |
DECLINED:NO_GZIP
originated by |
meaning |
mod_gzip_type_checker |
This request does contain an Accept-Encoding header but its list of encodings (that are supported by this UserAgent) doesn't contain the encoding gzip - obviously this UserAgent doesn't understand gzip-compressed data. |
DECLINED:NO_ACCEPT_ENCODING
originated by |
meaning |
mod_gzip_type_checker |
This request doesn't contain an Accept-Encoding header - obviously this UserAgent doesn't understand gzip-compressed data. |
DECLINED:NO_ITEMS_DEFINED
originated by |
meaning |
mod_gzip_type_checker |
The list of rules (to decide whether the content of the requested file is to be compressed) is empty (neither mod_gzip_include_item nor mod_gzip_exclude_item were used). Therefore the normal decision process is not applicable. |
DECLINED:REQ_HEADER_FIELD_EXCLUDED
originated by |
meaning |
mod_gzip_type_checker |
This request has been excluded from compression during the filter rules analysis
(mod_gzip_validate1 (header_name, header_value, MOD_GZIP_REQUEST) , line 2511).
(It must have been a rule of the type mod_gzip_exclude_item reqheader - it cannot have been caused by a missing mod_gzip_include_item rule as other tests are bound to follow.) |
DECLINED:EXCLUDED
originated by |
meaning |
mod_gzip_type_checker |
This request excluded from compression during the filter rules analysis (mod_gzip_validate1 (file, uri, content_type, handler) , line 2612), after the HTTP request header fields were already checked against mod_gzip_exclude_item rules.
(Not really meaningful, what a pity ... if we were told at least whether an explicit mod_gzip_exclude_item fired - and from which class - or only no mod_gzip_include_item was found ... !) |
COMMAND:VERSION
originated by |
meaning |
mod_gzip_do_command |
This request caused the execution of the mod_gzip status display command defined by the directive mod_gzip_command_version (version number and 'on '/'off ').
This command's output is so short (less than 100 bytes) that it wouldn't pay to compress the content. |
DECLINED:INVALID_COMMAND
originated by |
meaning |
mod_gzip_do_command |
Something must have crashed during the execution of the internal status command.
(I am not sure whether - and when - this case may ever happen.) |
INIT2
originated by |
meaning |
mod_gzip_handler |
This seems to be a value setting as initialization - at least it has no immediate effect on the order of processing. |
DECLINED:OFF2
originated by |
meaning |
mod_gzip_handler |
The compression mode has not been enabled for this file's definition scope (mod_gzip_on No for the complete Apache configuration, this virtual host, this directory or this .htaccess file) |
DECLINED:EXCLUDED_BY_HANDLER
originated by |
meaning |
mod_gzip_handler |
This request excluded from compression during the filter rules analysis (mod_gzip_validate1 (file, uri, content_type, handler) , line 3091), after the HTTP request header fields were already checked against mod_gzip_exclude_item rules.
(Not really meaningful, what a pity ... furthermore, I don't know why this must have been a handler causing the exclusion, as those four parameter values were fed into mod_gzip_validate1 as well.) |
RECOVERY
originated by |
meaning |
mod_gzip_handler |
Something must have gone wrong during the execution of mod_gzip_redir1_handler ... but what? We will have to do even an internal redirect, don't really know why ... and in line 3310 we will even overwrite our own status code with the one from this subrequest. |
DECLINED:DYN1_OPENFAIL_BODY
originated by |
meaning |
mod_gzip_redir1_handler |
mod_gzip_dyn1_getfdo1 has tried to create a new file, but failed.
(This access will finally result in a HTTP_INTERNAL_SERVER_ERROR - we won't get a usable result ... but why? Can't we still abort and DECLINE this compression request? And then, I would like to have more detailled information about what has gone wrong here ... why aren't they expressed by some status code?) |
STAT_FAILED
originated by |
meaning |
mod_gzip_sendfile2 |
The file to be sent doesn't exist. (stat() return code != 0); this seems to be one of these "this can't happen"events. |
CAP_FILE_EMPTY
originated by |
meaning |
mod_gzip_sendfile2 |
We do have a file to be sent (the stat() call has worked), but its size is less than 1 Byte. The document content to be compressed seems to have vanished somehow, why ever. |
CAP_FOPEN_FAILED
originated by |
meaning |
mod_gzip_sendfile2 |
We do have a file to be sent (the stat() call has worked), but the attempt to open it for reading (fopen(name,"rb") ) has failed. |
NO_HTTP_EOH
originated by |
meaning |
mod_gzip_sendfile2 |
The HTTP header of the result created during the current request processing was not terminated correctly. (While parsing the HTTP headers we should have found an empty line at line 5957.)
We cannot process such a header (we would have to partially rewrite it for compressing the content). |
NO_HTTP_RESP_CODE
originated by |
meaning |
mod_gzip_sendfile2 |
The HTTP header of the result created during the current request processing doesn't contain a status code. (In the first line of the HTTP header we should have found a HTTP status code, in line 5983.)
But just a bit later we will have to check exactly this status code - this won't work now, for sure |
SEND_AS_IS:NO_200
originated by |
meaning |
mod_gzip_sendfile2 |
The HTTP status code of the created response doesn't have the value 200 - and only for this value we may have some compressable document content.
(Um ... and what about all those 404 error documents?) |
SEND_AS_IS:RESPONSE_FIELD_EXCLUDED
originated by |
meaning |
mod_gzip_sendfile2 |
This request has been excluded from compression during the filter rules analysis
(mod_gzip_validate1 (header_name, header_value, MOD_GZIP_RESPONSE) , line 6081).
(This now obviously has been a HTTP header of the created result, as the rest hasn't been checked right now. For a DECLINED it is already to late now, this seems to make sense only before the original request processing ... ?) |
SEND_AS_IS:NO_BODY
originated by |
meaning |
mod_gzip_sendfile2 |
We do have a content with a usable HTTP header, but the size of this content is smaller than one byte. There simply isn't anthing there to be compressed. (For example, you get this status if a file with 0 bytes content is being accessed, like a dummy robots.txt file etc.) |
SEND_AS_IS:UNKNOWN_TE_VALUE
originated by |
meaning |
mod_gzip_sendfile2 |
The HTTP headers of the request's result contain a Transfer-Encoding which isn't of the chunked type that would have been the only one we had been able to handle(by joining the chunks one single packet and then compress this one). |
SEND_AS_IS:HAS_CE
originated by |
meaning |
mod_gzip_sendfile2 |
The HTTP headers of the request's result contain a Content-Encoding . In theory one would be able to cascade several Content-Encodings in HTTP; practical experience shows that none of the available UserAgents can handle that correctly. So we better let the content unchanged. |
SEND_AS_IS:NO_CONTENT_TYPE_IN_RESPONSE_HEADER
originated by |
meaning |
mod_gzip_sendfile2 |
The HTTP header of the request's result doesn't contain a Content-Type . (While parsing the HTTP headers we should have found a Content-type in line 6034.)
But the Content-type isn't a required header, according to HTTP; indeed the UserAgent may even guess a Content-type if none was delivered by the server. On the other hand the most important include rule is based upon this Content-type, and if there is none, then it will be difficult to make an according rule apply ...
I personally have eliminated just this test from mod_gzip for I get pages without Content-type via mod_proxy from a M$/IIS (but I know this ought to be text/html ) which I want to forward in compressed form ... |
SEND_AS_IS:RESPONSE_CONTENT_TYPE_EXCLUDED
originated by |
meaning |
mod_gzip_sendfile2 |
The request was excluded from compression during the filter rule analysis
(mod_gzip_validate1 (CONTENT_TYPE) , line 6307). |
SEND_AS_IS:DECHUNK_OPTION_IS_OFF
originated by |
meaning |
mod_gzip_sendfile2 |
A Transfer-Encoding: chunked was detectet, but in the configuration mod_gzip has not been allowed to remove this encoding (i. e. collect all chunks and join them to one packet, whose content would then be compressable). The directive mod_gzip_dechunk Yes would have allowed mod_gzip to compress this request. |
SEND_AS_IS:FOPEN_FAILED
originated by |
meaning |
mod_gzip_sendfile2 |
We were about to start compressing. For doing that it would have been necessary to open a temporary file whose name we let compute by mod_gzip_create_unique_filename before. But the attempt to open (write) this file has failed - therefore the attempt to compress data is terminated.
This may especially be the case if mod_gzip has just attempted to update the outdated content of a statically precompressed file but had no write access to this file. |
SEND_AS_IS:FSEEK_FAILED
originated by |
meaning |
mod_gzip_sendfile2 |
We were about to start compressing. After the input file has been opened successfully now we tried to position inside this file to the start position using fseek (ifh,0,0) - but this has failed.
(I am not yet sure why at this position it is already decided that data have to be read from a file and not from some Apache buffer ... we aren't in de-chunking mode yet?) |
SEND_AS_IS:BODY_MISSING
originated by |
meaning |
mod_gzip_sendfile2 |
During previous copying the content of the file to be compressed it has been detected that the content of this file contains of 0 bytes - therefore it makes no sense to compress anything. |
SEND_AS_IS:WORK_OPENFAIL
originated by |
meaning |
mod_gzip_open_output_file |
The attempt to reopen (read) the output file that has been created previously while compressing content (for sending these data now) has failed. |
OK / DECHUNK:OK
originated by |
meaning |
mod_gzip_encode_and_transmit |
The dompression has been completed successfully. (This value is set as default value at start of operation and overwritten in case of any error.) |
DECLINED:NO_ILEN / DECHUNK:DECLINED:NO_ILEN
originated by |
meaning |
mod_gzip_encode_and_transmit |
The size of the content to be compressed is smaller than one character - there's nothing to be done. |
DECLINED:TOO_SMALL / DECHUNK:DECLINED:TOO_SMALL
originated by |
meaning |
mod_gzip_encode_and_transmit |
The size of the compressed content is smaller than the value defined by the directive mod_gzip_minimum_file_size . |
DECLINED:TOO_BIG / DECHUNK:DECLINED:TOO_BIG
originated by |
meaning |
mod_gzip_encode_and_transmit |
The size of the compressed content is larger than the value defined by the directive mod_gzip_maximum_file_size . |
DECLINED:NO_OLEN / DECHUNK:DECLINED:NO_OLEN
originated by |
meaning |
mod_gzip_encode_and_transmit |
The size of the compressed content is smaller than one character - so something must have gone wrong during compression. |
DECLINED:ORIGINAL_SMALLER / DECHUNK:DECLINED:ORIGINAL_SMALLER
originated by |
meaning |
mod_gzip_encode_and_transmit |
The size of the compressed content is smaller than the size of the original content - so the compression has not lead to any saving. Therefore the uncompressed content will be served. |
DECLINED:REOPEN_FAILED / DECHUNK:DECLINED:REOPEN_FAILED
originated by |
meaning |
mod_gzip_encode_and_transmit |
The attempt to open (read) the output file (that has been created previously while compressing content) as to send these data has failed. |
TRANSMIT_ERROR:ISMEM:%d:%s / DECHUNK:TRANSMIT_ERROR:ISMEM:%d:%s
originated by |
meaning |
mod_gzip_encode_and_transmit |
Error while sending compressed data from main memory (message in DEBUG mode) |
TRANSMIT_ERROR:ISMEM:%d / DECHUNK:TRANSMIT_ERROR:ISMEM:%d
originated by |
meaning |
mod_gzip_encode_and_transmit |
Error while sending compressed data from main memory |
TRANSMIT_ERROR:%d / DECHUNK:TRANSMIT_ERROR:%d:%s
originated by |
meaning |
mod_gzip_encode_and_transmit |
Error while sending compressed data from the temporary file |
TRANSMIT_ERROR:%d / DECHUNK:TRANSMIT_ERROR:%d
originated by |
meaning |
mod_gzip_encode_and_transmit |
Error while sending compressed data from the temporary file |
SEND_AS_IS:PRECOMPRESSED_VARIANT_OUTDATED
originated by |
meaning |
mod_gzip_handler |
(new in mod_gzip 1.3.19.2a) The content of a statically precompressed file is older than the one of the uncompressed original file. Therefore the content of the original file has been served (in uncompressed form) - we rather serve correct data than outdated ones. |
DECLINED:METHOD_EXCLUDED
originated by |
meaning |
mod_gzip_type_checker |
(new in mod_gzip 1.3.19.2a) The request for this URL was made using a HTTP method whose results were not declared as to be compressed by using the mod_gzip_handle_methods directive. |
DECLINED:POST_TOO_BIG
originated by |
meaning |
mod_gzip_type_checker |
(new in mod_gzip 1.3.26.1a) The content length of a HTTP POST request is bigger than the available buffer and cannot be handled correctly by mod_gzip - this is a problem specific to the windows platform. The response to this request will be served in uncompressed form. |
OK:PRECOMPRESSED_VARIANT_UPDATED
originated by |
meaning |
mod_gzip_compress_file |
(new in mod_gzip 1.3.26.1a) While serving the content of a statically precompressed file it has been noticed that their content was older than the one of the corresponding original file. The content of the precompressed file has been updated successfully by compressing the original content once more; then the compressed content has been served. |
(Michael Schröpl, 2002-09-30)