Add unsafe initialisers for HTTPField and HTTPField.Name

[adam-fowler]

Currently when constructing an HTTPField or HTTPField.Name the values are checked to see if they are valid. This is the correct thing to do obviously when the source of the headers is unknown, but if we know in advance the headers are valid this is wasted effort.

The situation I am describing comes from building a SwiftNIO server which has constructed the header values via LLHTTP which validates they are correct and then we build a HTTPField from these that does the validation again.

Is there an argument for providing an unsafe initialiser for both HTTPField and HTTPField.Name to avoid this duplicate work

[guoye-zhang]

Yeah, that could be useful. Something like HTTPField.Name.init(unchecked name: String)?

I wouldn't expect llhttp to clear everything up though. If the field value contains lone CRs, we still have to parse it but would want to replace those with spaces before passing them to the client.

[adam-fowler]

I wouldn't expect llhttp to clear everything up though.

I don’t know, maybe @Lukasa knows

[FranzBusch]

I agree with @guoye-zhang that we probably can't use this proposed unchecked initialiser since the validation that lhttp does isn't fully matching what the current HTTPTypes inits do.

@adam-fowler You mentioned to me that you see a lot of time spent in these validating inits. It's worth getting an issue opened for that as well to see if we can optimise this more.