Bug #1069

No Content-Length in empty HEAD responses

Added by Antony Chazapis over 8 years ago. Updated over 5 years ago.

Status:Feedback Start date:09/08/2011
Priority:Medium Due date:
Assignee:- % Done:

0%

Category:Pithos Spent time: -
Target version:-

Description

Apache seems to cut the Content-Length header from empty HEAD replies.
When the reply has Content-Length > 0, it is kept.

This affects 'application/directory' objects for example.

Associated revisions

Revision aa62890f
Added by Antony Chazapis about 8 years ago

Document gunicorn deployment.

Refs #1067
Refs #1069
Refs #1073

Revision aa62890f
Added by Antony Chazapis about 8 years ago

Document gunicorn deployment.

Refs #1067
Refs #1069
Refs #1073

History

#1 Updated by Antony Chazapis about 8 years ago

  • Target version deleted (0.7 (alpha))

#2 Updated by Antony Chazapis about 8 years ago

This is an apache issue and persists when moving from mod_wsgi to gunicorn.

#3 Updated by Antony Chazapis about 8 years ago

This has been traced to 'modules/http/http_filters.c', line 1272, as part of the ap_http_header_filter() function. I have not tested this, but the code states:

    /* This is a hack, but I can't find anyway around it.  The idea is that
     * we don't want to send out 0 Content-Lengths if it is a head request.
     * This happens when modules try to outsmart the server, and return
     * if they see a HEAD request.  Apache 1.3 handlers were supposed to
     * just return in that situation, and the core handled the HEAD.  In
     * 2.0, if a handler returns, then the core sends an EOS bucket down
     * the filter stack, and the content-length filter computes a C-L of
     * zero and that gets put in the headers, and we end up sending a
     * zero C-L to the client.  We can't just remove the C-L filter,
     * because well behaved 2.0 handlers will send their data down the stack,
     * and we will compute a real C-L for the head request. RBB
     */
    if (r->header_only
        && (clheader = apr_table_get(r->headers_out, "Content-Length"))
        && !strcmp(clheader, "0")) {
        apr_table_unset(r->headers_out, "Content-Length");
    }

Seems that even if we comment out this part, it will break apache somewhere else.

#4 Updated by Antony Chazapis about 8 years ago

This has been traced to 'modules/http/http_filters.c', line 1272, as part of the ap_http_header_filter() function. I have not tested this, but the code states:

    /* This is a hack, but I can't find anyway around it.  The idea is that
     * we don't want to send out 0 Content-Lengths if it is a head request.
     * This happens when modules try to outsmart the server, and return
     * if they see a HEAD request.  Apache 1.3 handlers were supposed to
     * just return in that situation, and the core handled the HEAD.  In
     * 2.0, if a handler returns, then the core sends an EOS bucket down
     * the filter stack, and the content-length filter computes a C-L of
     * zero and that gets put in the headers, and we end up sending a
     * zero C-L to the client.  We can't just remove the C-L filter,
     * because well behaved 2.0 handlers will send their data down the stack,
     * and we will compute a real C-L for the head request. RBB
     */
    if (r->header_only
        && (clheader = apr_table_get(r->headers_out, "Content-Length"))
        && !strcmp(clheader, "0")) {
        apr_table_unset(r->headers_out, "Content-Length");
    }

Is just removing these lines a solution?

#5 Updated by Antony Chazapis over 7 years ago

  • Status changed from New to Feedback
  • Target version set to 1.0.0

#6 Updated by Vangelis Koukis almost 7 years ago

  • Project changed from Pithos to Synnefo
  • Target version deleted (1.0.0)

#7 Updated by Vangelis Koukis almost 7 years ago

  • Category set to Pithos

#8 Updated by Kostis Fardelas over 5 years ago

  • Assignee set to Kostis Fardelas

#9 Updated by Kostis Fardelas over 5 years ago

  • Assignee deleted (Kostis Fardelas)

Also available in: Atom PDF