mod_gzip status codes
Author: Michael Schröpl
Description: A summary of all status codes created by mod_gzip and an attempt to explain their meaning
Keywords: Apache, HTTP, encoding, gzip, compression

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