Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Content-Type isn't really an ambiguous case. It's invalid MIME - there can only be one Content-Type header in each part (RFC 2045 sec 3).

The problem is, neither clients nor servers want to enforce it because users will complain.



I just checked, and it doesn't say anything about how many Content-Type headers there can or cannot be.


The ABNF (RFC2045 section 3) specifies there can be either 0 or 1 in the message headers and message part headers:

    entity-headers := [ content CRLF ] 
                      [ encoding CRLF ] 
                      [ id CRLF ] 
                      [ description CRLF ]
                      *( MIME-extension-field CRLF )
Where content (section 5.1) is:

    content := "Content-Type" ":" type "/" subtype
                \*(";" parameter)


I missed that little detail, but even then, it doesn't matter. That just becomes a parse error and any half-decent parser can recover from that error. The important bit is that the spec doesn't specify how to recover, unlike html5, where it goes into great length to specify recovery so browsers are somewhat consistent. So, as the OC mentioned, some systems will recover by keeping the first one and some by keeping the last one, making it so various systems show different things.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: