gnustep
NSProtocol additional sanity check
Prevent setting headers if key or value are nil. I've encountered an URL where headers are corrupted and this causes internal exception within NSURLConnection.
Isn't this change (stopping the low level code from raising an exception) just hiding the actual issue? I would prefer to address the problem by making the higher level code check for it and refrain from setting bad header values. Perhaps the header is merely unusual rather than corrupt, but the parsing code is failing in some way? Can you provide a test case demonstrating the corrupt header (so we can see how that header is parsed/handled earlier on) ?
Isn't this change (stopping the low level code from raising an exception) just hiding the actual issue? I would prefer to address the problem by making the higher level code check for it and refrain from setting bad header values. Perhaps the header is merely unusual rather than corrupt, but the parsing code is failing in some way? Can you provide a test case demonstrating the corrupt header (so we can see how that header is parsed/handled earlier on) ?
Yes this is possible, although I wasn't able to debug this. I encountered this problem while downloading one of the OpenStep Previous images. https://winworldpc.com/download/3fc5bdc2-bde2-80a2-533f-11c3a4c2a90f
I changed NSURLResponse.m to warn about bad (missing) header values. Perhaps that will help determine where they are coming from?
I made setting nil equivalent to setting an empty string as a header value (some servers seem to do that) and allowed it.