Description of all mod_gzip status codes

Want to support HowtoForge? Become a subscriber!
 
Submitted by michael_schroepl (Contact Author) (Forums) on Fri, 2005-04-15 10:13. ::

Author: Michael Schröpl

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.
Original location of this document: http://www.schroepl.net/projekte/mod_gzip/status.htm

Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.