4 ms·

The answer is because that's what's in the spec. For HTTP, it's probably a mistake to hardcode header types. They are defined as key/value pairs of strings in t

by mbreese 13y ago

The answer is because that's what's in the spec. For HTTP, it's probably a mistake to hardcode header types. They are defined as key/value pairs of strings in the spec. There are a few keys that are specified, but how they actually work in practice (upper? lower? quoted?) is difficult to predict. There are just too many variations. So you end up with proper types for the most common ones, and then throw the extras into a separate "others" type. Which is great, except that now you have two places to check for things. In this case (HTTP), it's easier (and more correct) to just leave them as stings. The general principle with network protocols is to be strict in what you send, and forgiving in what you receive.

chrismorgan 13y ago
The headers are data, not text. Somewhere along the way you'll need to interpret them; doing a good job of that at the system boundary is the only sensible approach. (It's not the approach the majority of tools have taken, but it is the only sensible approach). If it gets into the system as text, people will start pulling it apart in even worse and less consistent ways. I agree with you that the parse behaviour for HTTP headers is poorly defined. That's something I'll be wrestling with all the time. Supported headers will be in one place and uncommon extension headers in another. Such, alas, is life. But really, the only time when I would expect this to cause any trouble at all is when new headers are added. Compare it with things like the CGI standard and how it handles headers and you'll realise it's not such a bad system. I should make it quite clear that the specs are (unfortunately) only a starting point for rust-http. Where there are deviations, more leniency may be added. But it'll be added thoroughly and properly.

4 ms·

The answer is because that's what's in the spec. For HTTP, it's probably a mistake to hardcode header types. They are defined as key/value pairs of strings in t

by mbreese 13y ago

chrismorgan 13y ago
The headers are data, not text. Somewhere along the way you'll need to interpret them; doing a good job of that at the system boundary is the only sensible approach. (It's not the approach the majority of tools have taken, but it is the only sensible approach). If it gets into the system as text, people will start pulling it apart in even worse and less consistent ways. I agree with you that the parse behaviour for HTTP headers is poorly defined. That's something I'll be wrestling with all the time. Supported headers will be in one place and uncommon extension headers in another. Such, alas, is life. But really, the only time when I would expect this to cause any trouble at all is when new headers are added. Compare it with things like the CGI standard and how it handles headers and you'll realise it's not such a bad system. I should make it quite clear that the specs are (unfortunately) only a starting point for rust-http. Where there are deviations, more leniency may be added. But it'll be added thoroughly and properly.