Professional Web Applications Themes

#25175 [Bgs]: session.use_trans_sid causes ob_get_length() to return incorrect value - PHP Development

ID: 25175 User updated by: phpbug at paypc dot com Reported By: phpbug at paypc dot com Status: Bogus Bug Type: Session related Operating System: Linux 2.4 PHP Version: 4.3.2 New Comment: ARGH... I had just rebuilt PHP (from the snapshot) and Apache.... the problem still exists, though Moriyoshi-san pretty much pre-confirmed it - I should have checked back here before embarking on a web-server rebuild. No worries. When I have trans_sid enabled, the discrepancy crops up again, but you knew that. I have not plumbed the depths of Zend and the output buffering part of PHP, but I'm surprised ...

  1. #1

    Default #25175 [Bgs]: session.use_trans_sid causes ob_get_length() to return incorrect value

    ID: 25175
    User updated by: phpbug at paypc dot com
    Reported By: phpbug at paypc dot com
    Status: Bogus
    Bug Type: Session related
    Operating System: Linux 2.4
    PHP Version: 4.3.2
    New Comment:

    ARGH... I had just rebuilt PHP (from the snapshot) and Apache.... the
    problem still exists, though Moriyoshi-san pretty much pre-confirmed it
    - I should have checked back here before embarking on a web-server
    rebuild. No worries.

    When I have trans_sid enabled, the discrepancy crops up again, but you
    knew that.

    I have not plumbed the depths of Zend and the output buffering part of
    PHP, but I'm surprised that this URL rewriting occurs at a level
    "higher" than that which obtaining the length of that buffer to be sent
    can be determined.

    I can understand the issues with the gzhandler readily enough - that's
    a "final pass" process which takes the entire output and compresses it
    prior to its flight to the client.

    If the gzhandler breaks trans_sid (or vice-versa), then I suspect
    someone make a bizarre design decision about where these various parts
    need to fit together.

    Transformation passes like trans_sid should be made before transport
    passes (like gzhandler) and functions which determine buffer length get
    at things.

    I would like to think that this is NOT a Bogus bug, but a bug whose fix
    is at least in the pipeline to be addressed. While it's easier to
    understand how the gzhandler problems would be an especially hard case
    to resolve, the ob_get_length() one shouldn't be.

    Or is the problem one where the URL rewriting happens while the data is
    actually IN-FLIGHT to the web-browser, after a possible response from
    the browser *AFTER* the header has been sent, but before the content?

    If the PHP team intends to never address this as a decision of policy,
    then retire this bug and place warnings into the doentation and FAQ.


    But if you intend to resolve it, I would think it retains some value to
    leave it as an open issue for future (and possibly unspecified) future
    resolution.

    Apollyon


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-08-22 13:48:47] [email]moriyoshiphp.net[/email]

    Technically, this is not a bug. Please see the following description.

    trans-sid (aka URL rewriter) utilises output buffering facility and it
    virtually works as a top level output buffer handler in the hanlder
    stack. Thus ob_get_length() might not reflect the actual length of the
    content being sent to the user-agent because trans-sid handler
    automatically rewrites all URL referrers of the tags that are specified
    by url_rewriter.tags in your php.ini so they contains session
    identifiers if the content includes any one of those tags. So, in any
    case ob_get_length() returns the size of the intact content, on which
    no URL transformation is applied yet. The same thing applies to
    zlib.output_compression.

    Then let me mark this PR bogus since this is not a bug in PHP. But this
    behaviour is rather confusing and will be addressed in the future
    versions.

    BTW, how on earth did you know I'm Japanese? :)

    ------------------------------------------------------------------------

    [2003-08-21 19:05:53] [email]sniperphp.net[/email]

    Please try using this CVS snapshot:

    [url]http://snaps.php.net/php4-STABLE-latest.tar.gz[/url]

    For Windows:

    [url]http://snaps.php.net/win32/php4-win32-STABLE-latest.zip[/url]




    ------------------------------------------------------------------------

    [2003-08-21 04:33:50] phpbug at paypc dot com

    *ARGH* I hate "thinkoes" -- it should be obvious from context (and
    perusing my phpconfig) that I've TURNED OFF enable_trans_sid, not
    turned it on.

    Upon re-reading my posting (naturally AFTER I'd hit submit), I noted
    the think-o.

    My apologies.

    =Apollyon=

    ------------------------------------------------------------------------

    [2003-08-21 04:31:10] phpbug at paypc dot com

    OK, let me put forth some declarations so we're talking apples and
    apples.

    My test method:

    echo -e "GET /legal/tester.php HTTP/1.1\r\nHost: 127.0.0.1\r\n" | nc
    127.0.0.1 80 > dump

    I wish to eliminate any possible "post-processing" or
    browser-variations.

    IE: "nc" is netcat, a commonly available network tool.

    OK, onto the results of my tests.

    I copied and pasted sniper's code *EXACTLY* as presented, with
    whitespaces and line spacing as entered. I obtained identical results
    with both lynx and my netcat method, though lynx probably doesn't
    support HTTP/1.1 because there was an additional header.

    With Lynx Version 2.8.3rel.1:

    HTTP/1.1 200 OK
    Date: Thu, 21 Aug 2003 09:10:16 GMT
    Server: Apache/1.3.27 Ben-SSL/1.48
    Connection-Type: Keep-Alive
    Content-Length: 4
    Connection: close <<<<<<<<<<<<< Additional header
    Content-Type: text/html

    With netcat:

    HTTP/1.1 200 OK
    Date: Thu, 21 Aug 2003 09:10:55 GMT
    Server: Apache/1.3.27 Ben-SSL/1.48
    Connection-Type: Keep-Alive
    Content-Length: 4
    Content-Type: text/html

    In comparing the actual bytes sent over the wire against the advertised
    content-length, the Content-Length header is correct.

    If you wish to inspect my PHP build and setup configuration, you may do
    so at: <http://hollywood.paypc.com/config4phpbugmasters>

    (I will be removing this after 24 hours.)

    And yes, it's pretty loaded. And yes, trans_sid is enabled, but in all
    of my test harnesses which employ sessions, I've enabled cookies - and
    they are created/used by the browsers involved.

    ******* AHHHHHHAAAA *******

    Arigatoo gozaimaa to Moriyoshi-san for cautioning me to turn on
    trans_sid, because when I disable it in my global php.ini, the
    discrepancy disappears!

    For my "complex" web-application which formerly reported bad sizing, I
    received the following header (after turning off trans_sid):

    ----------------------------
    HTTP/1.1 200 OK
    Date: Thu, 21 Aug 2003 09:20:47 GMT
    Server: Apache/1.3.27 Ben-SSL/1.48
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
    pre-check=0
    Pragma: no-cache
    Set-Cookie: PHPSESSID=a1c8bfb3f409580e57206d7c19eac473; path=/
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Content-Length: 2825
    Content-Type: text/html
    --------------------------------

    And doing a wc -c on the content-portion matches this size exactly
    (with my netcat test).

    Third-party validation via usage of
    <http://www.ircache.net/cgi-bin/cacheability.py> confirms an exact
    match of advertised Content-Length and what's actually received.

    And lastly, and most importantly, the IE "hang" bug while accessing
    this web application via an intranet is gone.

    OK, fine, trans_sid broke it. Why? And should it have? I'm
    suspicious that the Esteemed Moriyoshi-san nailed this specific setting
    in advance, as if to suspect it being a potential cause for buggage.

    Inquiring minds want to know - if it's by design, please add it to the
    doentation and FAQ. I know alot of things about the ob_ functions
    are unusual and cause some people hardship (of their own making). This
    one came out of left field.

    =Apollyon=

    ------------------------------------------------------------------------

    [2003-08-21 00:10:00] [email]moriyoshiphp.net[/email]
    > Set-Cookie: PHPSESSID=2989258979bd07405999448563ef4bfc; path=/
    Perhaps you seem to have enabled session.use_trans_sid.
    If so, first turn it off before trying the above script provided by
    sniper.

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    [url]http://bugs.php.net/25175[/url]

    --
    Edit this bug report at [url]http://bugs.php.net/?id=25175&edit=1[/url]

    phpbug at paypc dot com Guest

  2. #2

    Default #25175 [Bgs]: session.use_trans_sid causes ob_get_length() to return incorrect value

    ID: 25175
    Updated by: [email]moriyoshiphp.net[/email]
    Reported By: phpbug at paypc dot com
    Status: Bogus
    Bug Type: Session related
    Operating System: Linux 2.4
    PHP Version: 4.3.2
    New Comment:

    As the doentation says, ob_get_length() returns the length of the
    current output buffer. It's not supposed to return the length of the
    actual HTTP content, while it's also the case those values are often
    the same. I'm afraid, that you cannot do it right with the current
    version of PHP.

    One can say this is a design issue, but it's not an actual bug,
    although we can deem it as a feature request. So it'd be better to file
    a new report for such a function that returns the content length than
    turn this report into a request, which may cause confusion on other
    people using this bug database.

    Thanks.



    Previous Comments:
    ------------------------------------------------------------------------

    [2003-08-23 04:47:49] phpbug at paypc dot com

    ARGH... I had just rebuilt PHP (from the snapshot) and Apache.... the
    problem still exists, though Moriyoshi-san pretty much pre-confirmed it
    - I should have checked back here before embarking on a web-server
    rebuild. No worries.

    When I have trans_sid enabled, the discrepancy crops up again, but you
    knew that.

    I have not plumbed the depths of Zend and the output buffering part of
    PHP, but I'm surprised that this URL rewriting occurs at a level
    "higher" than that which obtaining the length of that buffer to be sent
    can be determined.

    I can understand the issues with the gzhandler readily enough - that's
    a "final pass" process which takes the entire output and compresses it
    prior to its flight to the client.

    If the gzhandler breaks trans_sid (or vice-versa), then I suspect
    someone make a bizarre design decision about where these various parts
    need to fit together.

    Transformation passes like trans_sid should be made before transport
    passes (like gzhandler) and functions which determine buffer length get
    at things.

    I would like to think that this is NOT a Bogus bug, but a bug whose fix
    is at least in the pipeline to be addressed. While it's easier to
    understand how the gzhandler problems would be an especially hard case
    to resolve, the ob_get_length() one shouldn't be.

    Or is the problem one where the URL rewriting happens while the data is
    actually IN-FLIGHT to the web-browser, after a possible response from
    the browser *AFTER* the header has been sent, but before the content?

    If the PHP team intends to never address this as a decision of policy,
    then retire this bug and place warnings into the doentation and FAQ.


    But if you intend to resolve it, I would think it retains some value to
    leave it as an open issue for future (and possibly unspecified) future
    resolution.

    Apollyon

    ------------------------------------------------------------------------

    [2003-08-22 13:48:47] [email]moriyoshiphp.net[/email]

    Technically, this is not a bug. Please see the following description.

    trans-sid (aka URL rewriter) utilises output buffering facility and it
    virtually works as a top level output buffer handler in the hanlder
    stack. Thus ob_get_length() might not reflect the actual length of the
    content being sent to the user-agent because trans-sid handler
    automatically rewrites all URL referrers of the tags that are specified
    by url_rewriter.tags in your php.ini so they contains session
    identifiers if the content includes any one of those tags. So, in any
    case ob_get_length() returns the size of the intact content, on which
    no URL transformation is applied yet. The same thing applies to
    zlib.output_compression.

    Then let me mark this PR bogus since this is not a bug in PHP. But this
    behaviour is rather confusing and will be addressed in the future
    versions.

    BTW, how on earth did you know I'm Japanese? :)

    ------------------------------------------------------------------------

    [2003-08-21 19:05:53] [email]sniperphp.net[/email]

    Please try using this CVS snapshot:

    [url]http://snaps.php.net/php4-STABLE-latest.tar.gz[/url]

    For Windows:

    [url]http://snaps.php.net/win32/php4-win32-STABLE-latest.zip[/url]




    ------------------------------------------------------------------------

    [2003-08-21 04:33:50] phpbug at paypc dot com

    *ARGH* I hate "thinkoes" -- it should be obvious from context (and
    perusing my phpconfig) that I've TURNED OFF enable_trans_sid, not
    turned it on.

    Upon re-reading my posting (naturally AFTER I'd hit submit), I noted
    the think-o.

    My apologies.

    =Apollyon=

    ------------------------------------------------------------------------

    [2003-08-21 04:31:10] phpbug at paypc dot com

    OK, let me put forth some declarations so we're talking apples and
    apples.

    My test method:

    echo -e "GET /legal/tester.php HTTP/1.1\r\nHost: 127.0.0.1\r\n" | nc
    127.0.0.1 80 > dump

    I wish to eliminate any possible "post-processing" or
    browser-variations.

    IE: "nc" is netcat, a commonly available network tool.

    OK, onto the results of my tests.

    I copied and pasted sniper's code *EXACTLY* as presented, with
    whitespaces and line spacing as entered. I obtained identical results
    with both lynx and my netcat method, though lynx probably doesn't
    support HTTP/1.1 because there was an additional header.

    With Lynx Version 2.8.3rel.1:

    HTTP/1.1 200 OK
    Date: Thu, 21 Aug 2003 09:10:16 GMT
    Server: Apache/1.3.27 Ben-SSL/1.48
    Connection-Type: Keep-Alive
    Content-Length: 4
    Connection: close <<<<<<<<<<<<< Additional header
    Content-Type: text/html

    With netcat:

    HTTP/1.1 200 OK
    Date: Thu, 21 Aug 2003 09:10:55 GMT
    Server: Apache/1.3.27 Ben-SSL/1.48
    Connection-Type: Keep-Alive
    Content-Length: 4
    Content-Type: text/html

    In comparing the actual bytes sent over the wire against the advertised
    content-length, the Content-Length header is correct.

    If you wish to inspect my PHP build and setup configuration, you may do
    so at: <http://hollywood.paypc.com/config4phpbugmasters>

    (I will be removing this after 24 hours.)

    And yes, it's pretty loaded. And yes, trans_sid is enabled, but in all
    of my test harnesses which employ sessions, I've enabled cookies - and
    they are created/used by the browsers involved.

    ******* AHHHHHHAAAA *******

    Arigatoo gozaimaa to Moriyoshi-san for cautioning me to turn on
    trans_sid, because when I disable it in my global php.ini, the
    discrepancy disappears!

    For my "complex" web-application which formerly reported bad sizing, I
    received the following header (after turning off trans_sid):

    ----------------------------
    HTTP/1.1 200 OK
    Date: Thu, 21 Aug 2003 09:20:47 GMT
    Server: Apache/1.3.27 Ben-SSL/1.48
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
    pre-check=0
    Pragma: no-cache
    Set-Cookie: PHPSESSID=a1c8bfb3f409580e57206d7c19eac473; path=/
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Content-Length: 2825
    Content-Type: text/html
    --------------------------------

    And doing a wc -c on the content-portion matches this size exactly
    (with my netcat test).

    Third-party validation via usage of
    <http://www.ircache.net/cgi-bin/cacheability.py> confirms an exact
    match of advertised Content-Length and what's actually received.

    And lastly, and most importantly, the IE "hang" bug while accessing
    this web application via an intranet is gone.

    OK, fine, trans_sid broke it. Why? And should it have? I'm
    suspicious that the Esteemed Moriyoshi-san nailed this specific setting
    in advance, as if to suspect it being a potential cause for buggage.

    Inquiring minds want to know - if it's by design, please add it to the
    doentation and FAQ. I know alot of things about the ob_ functions
    are unusual and cause some people hardship (of their own making). This
    one came out of left field.

    =Apollyon=

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    [url]http://bugs.php.net/25175[/url]

    --
    Edit this bug report at [url]http://bugs.php.net/?id=25175&edit=1[/url]
    moriyoshi@php.net Guest

Similar Threads

  1. Replies: 0
    Last Post: August 22nd, 06:48 PM
  2. Replies: 0
    Last Post: August 22nd, 12:06 AM
  3. #25175 [Fbk->Opn]: ob_get_length() returns incorrect value
    By phpbug at paypc dot com in forum PHP Development
    Replies: 1
    Last Post: August 21st, 09:42 AM
  4. #25175 [Fbk]: ob_get_length() returns incorrect value
    By moriyoshi@php.net in forum PHP Development
    Replies: 0
    Last Post: August 21st, 05:10 AM
  5. #25175 [Opn->Fbk]: ob_get_length() returns incorrect value
    By moriyoshi@php.net in forum PHP Development
    Replies: 1
    Last Post: August 21st, 03:54 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139