Http_printf( pHttpHandle, "<span><script type='text/javascript' language='javascript'>document.write(ReplaceUnderscores('%s'));</script></span>", visit->name );



  • There are so many wrong with this code that I stopped counting, and just started fixing. But this summerizes some, I think:

    [code]http_printf( pHttpHandle, "<script type='text/javascript' language='javascript'>document.write(ReplaceUnderscores('%s'));</script>", visit->name );[/code]


    We've got:

    Hardcoded html in C code.

    Roll your own webserver...

    Which writes all the http_printf to a temp file and then sends this file.

    Using document.write javascript...

    To replace underscores (with? spaces in this case)...

    On text that is 1) static, 2) never has underscores...

    And should be done serverside anyhow.



    If I ever find the person who made this then I'll be on the news. "Skinny geek pulls head of person because of rage."



    I also have frames, with an iframe in the main frame, which contains... another iframe.



  • @Daid said:

    "Skinny geek pulls head of person because of rage."
    I call this CodeRage.



  •  @Daid said:

    Using document.write javascript...

    Actually, I think this has been officially un-deprecated with the advent of HTML5.

    From what I know,  it was discouraged when we all were supposed to switch to XHTML, because it obviously doesn't work with any sane method of XML parsing.

    HTML5 didn't bother with restricting itself to sane parsing methods and directly integrated it into the parsing process. This has the fun side effect that you can write HTML5 documents which are theoretically un-validateable due to the halting problem. But for all practical purposes, it means that it's a perfectly valid - and specced - way to generate HTML.



  • Actually TRWTF is the title of this post.

    Seriously?  You couldn't come up with something that didn't look broken yourself?

     



  • @KattMan said:

    Actually TRWTF is the title of this post.

    Seriously?  You couldn't come up with something that didn't look broken yourself?

    It's just WTF bonus material if the forum software or users' MUAs choke on it.



  • @PSWorx said:

     @Daid said:

    Using document.write javascript...

    Actually, I think this has been officially un-deprecated with the advent of HTML5.

    From what I know,  it was discouraged when we all were supposed to switch to XHTML, because it obviously doesn't work with any sane method of XML parsing.

    HTML5 didn't bother with restricting itself to sane parsing methods and directly integrated it into the parsing process. This has the fun side effect that you can write HTML5 documents which are theoretically un-validateable due to the halting problem. But for all practical purposes, it means that it's a perfectly valid - and specced - way to generate HTML.

    document.write() is still a bad idea, regardless of what version of HTML you're using. Practically, though, it's pretty necessary for a lot of tasks... imagine implementing something like Omniture Test&Target without document.write().


  • ♿ (Parody)

    @blakeyrat said:

    document.write() is still a bad idea, regardless of what version of HTML you're using. Practically, though, it's pretty necessary for a lot of tasks... imagine implementing something like Omniture Test&Target without document.write().

    Would they really need that? Can't that stuff be generated server side? Admittedly, my only knowledge of this product is from a few minutes on their site.



  • @boomzilla said:

    @blakeyrat said:
    document.write() is still a bad idea, regardless of what version of HTML you're using. Practically, though, it's pretty necessary for a lot of tasks... imagine implementing something like Omniture Test&Target without document.write().

    Would they really need that? Can't that stuff be generated server side? Admittedly, my only knowledge of this product is from a few minutes on their site.

    It's possible it could be implemented using AJAX, but that's a lot more error-prone, and it's a lot more likely to be incompatible with existing JS already on the site, and it would probably produce a bad user experience because the user would have to wait longer before seeing the content, and you wouldn't be able to serve up JS in a mbox... on the other hand, if T&T's servers went down, this wouldn't necessarily break the site.

    I was working on a T&T-like testing tool for one of my clients, intending to avoid document.write() and it worked-- but that was on a specific site I knew, with specific content that I was aware of, none of which involved serving JS. But I definitely understand why T&T implemented it the way they did.



  •  @blakeyrat said:

    document.write() is still a bad idea, regardless of what version of HTML you're using.

    I know you shouldn't use it after the page has finished loading, unless you like ending up in the twilight zone of browser incompatibillities. And you can catch an XSS vulnerabillity if you behave exceptionally stupid (you can do that with innerHTML too, though). But both problems can be easily avoided. Why else should you not use it?

     (Disclaimer: Of course when ever you CAN use standard DOM methods, you should prefer them. But as you said, there are a number of things that either can't be done via DOM or would be very inefficient. So for those situations, I'd see it as a valid tool.)



  • I was wrong... this is only the tip of the iceberg. The rest of the code is WORSE. It's like, "how to put as many buffer overflow possibilities in a single piece of outside facing code!"



    And then there is this buffer called "post" which is used all over the code, as just a buffer for different purposes. And what normal people call "headers" here is called "request parameters"

    Abbreviations everywhere! why write "name" if "nm" saves you a wopping 50% typing!

    It uses about the same amount of memory as all other processes combined on my device (embedded configuration webinterface)



  • @Daid said:

    I was wrong... this is only the tip of the iceberg. The rest of the code is WORSE. It's like, "how to put as many buffer overflow possibilities in a single piece of outside facing code!"

    And then there is this buffer called "post" which is used all over the code, as just a buffer for different purposes. And what normal people call "headers" here is called "request parameters"
    Abbreviations everywhere! why write "name" if "nm" saves you a wopping 50% typing!
    It uses about the same amount of memory as all other processes combined on my device (embedded configuration webinterface)
    People still write Internet facing applications in languages that are capable of buffer overflows?  That's a far bigger WTF that any of the details of the implementation.



  • @Jaime said:

    People still write Internet facing applications in languages that are capable of buffer overflows?  That's a far bigger WTF that any of the details of the implementation.

    Who said anything about internet facing?
    Also, how are you planning to fit your fancy buffer overflow free Java/Python/Whatever(TM) webserver in my 16MB ram, and leave room for everything else? Or, in reality, it's currently using 3-5MB ram, which is way to much for the system already.



  • @Daid said:

    Also, how are you planning to fit your fancy buffer overflow free Java/Python/Whatever(TM) webserver in my 16MB ram, and leave room for everything else? Or, in reality, it's currently using 3-5MB ram, which is way to much for the system already.

    But it's writing everything out to a temp file before sending it across http? gag...


  • ♿ (Parody)

    @Xyro said:

    But it's writing everything out to a temp file before sending it across http? gag...

    Seems like something called http_printf is more likely to write that out over the network as, erm, http traffic.



  • @Daid said:

    @Jaime said:

    People still write Internet facing applications in languages that are capable of buffer overflows?  That's a far bigger WTF that any of the details of the implementation.

    Who said anything about internet facing? Also, how are you planning to fit your fancy buffer overflow free Java/Python/Whatever(TM) webserver in my 16MB ram, and leave room for everything else? Or, in reality, it's currently using 3-5MB ram, which is way to much for the system already.
    DD-WRT is a replacement firmware for consumer routers.  It manages to get a real http server and PHP in 8MB of RAM.

  • ♿ (Parody)

    @Jaime said:

    DD-WRT is a replacement firmware for consumer routers.  It manages to get a real http server and PHP in 8MB of RAM.

    Although apparently, 8MB is insufficient for that to always work. It's hard to say, without knowing what the OP is doing, obviously.



  • @boomzilla said:

    @Xyro said:
    But it's writing everything out to a temp file before sending it across http? gag...

    Seems like something called http_printf is more likely to write that out over the network as, erm, http traffic.
    I assumed the same, until I read the code. It buffers the whole output in a temp file (in /tmp/ which is a tmpfs, luckly) and then sends that file over. If you want to send it directly you can use http_write, but then you need to emit the http headers first.

    The whole problem code comes from the fact that the person who made it never heart about "chunked encoding" and thus needs the whole output size ("content-size: xx") before it can send the headers.



    Of the 3-5mb only 640k is used in the http server as buffers, the rest is the configuration data I guess, or the half assed XML library leaking memory on startup. It also has 4 threads handling 32 connections...



  • @Daid said:

    @Jaime said:

    People still write Internet facing applications in languages that are capable of buffer overflows?  That's a far bigger WTF that any of the details of the implementation.

    Who said anything about internet facing?
    Also, how are you planning to fit your fancy buffer overflow free Java/Python/Whatever(TM) webserver in my 16MB ram, and leave room for everything else? Or, in reality, it's currently using 3-5MB ram, which is way to much for the system already.

    My original generation Motorola RAZR had no problem running graphical Java apps in its 10 MB of memory.


Log in to reply