4 ms·

IMHO, libraries like this should always have an easy "out", where the default is strongly typed, but the user of the library can explicitly escape the known beh

by axiak 13y ago

IMHO, libraries like this should always have an easy "out", where the default is strongly typed, but the user of the library can explicitly escape the known behavior if need be. As a (albeit poor example), I once inherited a click tracking system that uses Java Jersey. The standard response object has a .redirect(URI uri) method. Unfortunately, many "URI"s we receive from the world are not actually value, and the java URI object refuses to build URI objects from the string. Fortunately, one can simply call .setHeader(String, String) and be done with it.

chrismorgan 13y ago
At present, in rust-http, invalid values will be dropped; that will be changing so that you can retrieve a bad header value (https://github.com/chris-morgan/rust-http/issues/27 https://github.com/chris-morgan/rust-http/issues/27). Writing invalid HTTP, on the other hand, is something that I'm in two minds about. You shouldn't be allowed to do it, but it may be necessary somewhere along the way. At present, you can write invalid headers through the use of the extension headers—`response.headers.extension.set(~"Date", ~"invalid")`, for example. I certainly don't want to advertise it broadly, but I'm thinking guaranteeing that that will always work is perhaps the best plan.
- timtadh 13y ago
  You should always allow the user to get the raw HTTP request. Sometimes things just get funky and you need to drop down to that level. Abstraction is nice except when it isn't, if you understand my meaning.
- zaphar 13y ago
  The author isn't wanting to write invalid headers. He's wanting to write perfectly valid headers that the framework he's using didn't allow him to write. When the framework treats a a valid http header as invalid the framework is probably using the wrong abstraction for http headers.
  - ethzero 13y ago
    Spray allows you to define custom (even invalid) headers, all you have to do is subclass HttpHeader. I'm sure the author knew this, but it's not obvious from his criticism.

by axiak 13y ago

chrismorgan 13y ago

At present, in rust-http, invalid values will be dropped; that will be changing so that you can retrieve a bad header value (https://github.com/chris-morgan/rust-http/issues/27 https://github.com/chris-morgan/rust-http/issues/27). Writing invalid HTTP, on the other hand, is something that I'm in two minds about. You shouldn't be allowed to do it, but it may be necessary somewhere along the way. At present, you can write invalid headers through the use of the extension headers—`response.headers.extension.set(~"Date", ~"invalid")`, for example. I certainly don't want to advertise it broadly, but I'm thinking guaranteeing that that will always work is perhaps the best plan.

timtadh 13y ago
You should always allow the user to get the raw HTTP request. Sometimes things just get funky and you need to drop down to that level. Abstraction is nice except when it isn't, if you understand my meaning.
zaphar 13y ago
The author isn't wanting to write invalid headers. He's wanting to write perfectly valid headers that the framework he's using didn't allow him to write. When the framework treats a a valid http header as invalid the framework is probably using the wrong abstraction for http headers.
- ethzero 13y ago
  Spray allows you to define custom (even invalid) headers, all you have to do is subclass HttpHeader. I'm sure the author knew this, but it's not obvious from his criticism.