Header beautification



  • How can one mess with http headers? Include newlines to separate logical parts, of course. And some indentation.
     

    header("
        SetEnvIf User-Agent \".*MSIE.*\"
        nokeepalive ssl-unclean-shutdown
        downgrade-1.0 force-response-1.0
    ");

     

    See? It looks better! Who cares what it actually does?



  • @Kiss me I'm Polish said:

    How can one mess with http headers? Include newlines to separate logical parts, of course. And some indentation.
     

    header("
        SetEnvIf User-Agent ".MSIE."
        nokeepalive ssl-unclean-shutdown
        downgrade-1.0 force-response-1.0
    ");

     

    See? It looks better! Who cares what it actually does?

     
    Umm, you do know that HTTP headers are allowed to be split across
    multiple lines and that any line that begins with whitespace means a
    continuation of the previous line, yeah?  Read the RFC if not...

     



  • I did not know that.

    I wonder if any of the major webservers / web-browsers support it?

    (Making a webserver in my free time, currently serves one fixed page and can return 6 different errors)
     



  • Allowed or not, it would probably look better | be more readable on one line



  • header('SetEnvIf User-Agent "MSIE*"
     nokeepalive
     ssl-unclean-shutdown
     downgrade-1.0
     force-response-1.0
    ');

     And since this is probably php, using single quotes removes the need to unescape the double quotes inside the string since everything will be interpreted literally.



  • Does apache even care about the environment variables that is set at this stage?

    Also, what is wrong with the normal environment variable editing functions? 



  • @Thief^ said:

    I did not know that.

    I wonder if any of the major webservers / web-browsers support it?

    Yes, absolutely every single one.  Seriously, it's a fundamental part of the HTTP protocol.

     

    (Making a webserver in my free time, currently serves one fixed page and can return 6 different errors)

    Well, if your webserver has no need for continued header lines, it does not have to generate any, but it should at least be able to cope if it receives them in the browser's request.  But certainly, you don't need to implement every feature and corner-case of the http specification if you just have a very limited simple project in mind.

     

     



  • @DaveK said:

    @Kiss me I'm Polish said:

    How can one mess with http headers? Include newlines to separate logical parts, of course. And some indentation.
     

    header("
        SetEnvIf User-Agent ".MSIE."
        nokeepalive ssl-unclean-shutdown
        downgrade-1.0 force-response-1.0
    ");

     

    See? It looks better! Who cares what it actually does?

     
    Umm, you do know that HTTP headers are allowed to be split across
    multiple lines and that any line that begins with whitespace means a
    continuation of the previous line, yeah?  Read the RFC if not...

    hm, this is interesting. Didn't know that yet either.
    I can't believe that empty lines are allowed though, since they are already used to seperate the headers from the payload. So the above example would still be invalid.
    Also, at least in PHP, the haeader() function seems to do some pretty unnecessary parsing by itself (So for example it replaces some headers but just adds others at the bottom of the list, depending what is allowed for the specific header. For 'location' headers, it even changes the status code.)
    So even if the browsers understand it, given the usual quality of PHP I don't think it's very likely PHP does.
     



  • @PSWorx said:

    I can't believe that empty lines are allowed though, since they are already used to seperate the headers from the payload.

    Lines containing only whitespace is allowed, because the spec says that the headers finish after the first sequence of CRLF + CRLF. So if you have CRLF + SPACE + CRLF and the next line starts with whitespace, this line is the remaining of the previous header; if the next line doesn't start with whitespace, it's simply another header.

    By the way, I've also tried writing a Web server with VB 2005. It actually works and it is customizable! If I'm online, you can see it working live at http://fragag.is-a-geek.com/ (warning: it's in French, made in XML+XSLT and it could crash your browser if you're unlucky). Look at the headers sent by the server as a proof of it.



  • Ah, took me a while to find it: http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html

     
    "HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. "



  • Well, you guys got it right. Some of you :D

    The "header" had two lines containing only CRLF - one at the beginning, one at the end.

    Whitespace at continuation of previous line - yep, but not at the first line, right?

    And no, php doesn't fix the extra CRLF lines in the headers for you - this beauty appeared in the browser at the beginning of the script when I fired it up. Every time.



  • @DaveK said:

    @Thief^ said:

    (Making a webserver in my free time, currently serves one fixed page and can return 6 different errors)

    Well, if your webserver has no need for continued header lines, it does not have to generate any, but it should at least be able to cope if it receives them in the browser's request.  But certainly, you don't need to implement every feature and corner-case of the http specification if you just have a very limited simple project in mind.

    I'm actually doing it for fun. I enjoy finding out how things work, and I've written some simple webservers in other languages before. It's generally pretty easy to write a webserver that will work with a major browser, but I wanted to write one that behaved a lot better than my previous attempts. Most of the others were vulnerable to the "/../" attack for example, and only had 200 and 404 return codes. Most of them crashed if the webserver didn't have permission to read the requested file, etc.

    That's a point, what should a webserver do if it gets a request for a path with /../ in? Attempt to parse it or 404? If it's parsing it, what about /abc/../ where /abc/ doesn't exist or the user doesn't have permissions?


  • @Thief^ said:

    (Making a webserver in my free time, currently serves one fixed page and can return 6 different errors)
     

     

    Just what the world needs, another IIS clone :) 



  • I appreciate the humour but I'm actually writing it for linux :)



  • @Kiss me I'm Polish said:

    How can one mess with http headers?

    By putting apache configuration directives rather than actual headers in them?  


Log in to reply