php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #39 Stronghold crashes when secure pages served
Submitted: 1998-02-06 03:08 UTC Modified: 1998-02-12 19:47 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: elfchief at lupine dot org Assigned:
Status: Closed Package: Other
PHP Version: 3.0b4 OS: Solaris 2.5.1 x86
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: elfchief at lupine dot org
New email:
PHP Version: OS:

 

 [1998-02-06 03:08 UTC] elfchief at lupine dot org 
Okay, works fine, except when I try to have a page served
by a secure virtual server under Stronghold. Normally,
things work fine, but a <? tag anywhere in a document
will cause Stronghold to segfault nicely when my request
is going to an SSL-enrypted virtual server.

Here's a stack trace. (compiled with stronghold debugging
off, php debugging on. Let me know if you need more)

#0  0x80119f30 in kill ()
#1  0x800ea8e5 in abort ()
#2  0x8067d88 in just_die ()
#3  <signal handler called>
#4  0x4 in ?? ()
#5  0xffffffff in ?? ()
#6  0x80c02d7 in lex_scan (phplval=0x17) at language-scanner.c:571
#7  0x80a118e in read_next_token (tcm=0x814e454, token=0x8046674, 
    phplval=0x8046778) at token_cache.c:132
#8  0x809c18c in phplex (phplval=0x8046778) at main.c:395
#9  0x80b980b in phpparse () at language-parser.tab.c:387
#10 0x809d497 in php3_parse (yyin=0x814e9c8) at main.c:1210
#11 0x809d652 in apache_php3_module_main (r=0x8191bc4, fd=22, 
    display_source_mode=0, preprocessed=0) at main.c:1500
#12 0x8083acc in send_php3 ()
#13 0x8083b2c in send_parsed_php3 ()
#14 0x806bcb9 in invoke_handler ()
#15 0x806e7c1 in process_request_internal ()
#16 0x806e7fa in process_request ()
#17 0x8068955 in child_main ()
#18 0x8068ade in make_child ()
#19 0x80690f1 in standalone_main ()
#20 0x8069618 in main ()


... Help!?!?

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1998-02-12 19:47 UTC] zeev 
Fixed.  Stronghold has NULL elements on the
apache environment table, and hash_environment()
was trying to copy a string from there.
 [2010-10-10 21:05 UTC] cataphract@php.net 
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=304287
Log: - Revamp of the decoding portion of html.c.
- Dramatic improvements on the performance of html_entity_decode and htmlspecialchars_decode, as the
  string is now traversed only once. Speedups of 20 to 25 times with Windows release builds and a
  ~250 characters string (for 2nd and subsequent calls).
- Consistent behavior on html_entity_decode. For instance, the entity in &quot;&amp;&amp;lt;&quot; would be decoded,
  but not &quot;&amp;&amp;#233;&quot;. Not anymore. The code path for &quot;basic&quot; and non-basic entities is now mostly
  shared.
- Code of html_entity_decode and htmlspecialchars_decode is now shared.
- [DOC] More consistent behavior of htmlspecialchars_decode. Instead of translating only &amp;lt;, &amp;gt;,
  &amp;amp;, &amp;quot;, &amp;#039; and &amp;#39;, now e.g. &amp;#34;, &amp;apos;, &amp;#0039;, &amp;#x27;, etc. are also decoded.
- [DOC] Previous translation of unicode code points in numerical entities was seriously broken. When
  the code points for some character were not the same in unicode and the target encoding, the
  behavior could be an erroneous translation (e.g. 0x80-0xA0 in win-1252) or no translation at all.
  Added unicode translation tables for all single-byte encodings. Entities are not translated for
  multi-byte entities, except for ASCII characters whose code points are shared. We could add
  the huge translation tables (several thousand elements) for those encodings in the future.
- Fixed numerical entities that after # had text accepted by strcol being accepted.
- Much more commented and well-structured code...
- Tests for get_html_translation_table()) are broken. I stared fixing the tests, but then I realized
  it was completely helpless because get_html_translation_table() is broken by not handling
  multi-byte characters correctly.
 [2010-10-12 04:51 UTC] cataphract@php.net 
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=304340
Log: - Added a 3rd parameter to get_html_translation_table. It now takes a charset
  hint, like htmlentities et al.
- Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8).
- Fixed bug #25927 (get_html_translation_table calls the ' &amp;#39; instead of
  &amp;#039;).
- Fixed tests for get_html_translation_table and unified the Windows and
  non-Windows versions of the tests.
 [2011-09-09 12:54 UTC] rquadling@php.net 
Automatic comment from SVN on behalf of rquadling
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=316456
Log: Entities containing d' and l' =&gt; d&amp;#39; and l&amp;#39;
 [2016-06-25 23:35 UTC] cmb@php.net 
Automatic comment from SVN on behalf of cmb
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=339499
Log: Address #67811: htmlspecialchars: document why/when apos instead of #39 is used
 
PHP Copyright © 2001-2023 The PHP Group
All rights reserved. 		Last updated: Sun Oct 01 17:01:23 2023 UTC