> All right, it seems that there are consensus regarding this issue. Anyone > here have any idea of an ETA for the fix?
You'll have to ask the web site, as that's what needs fixing. All that can be done to Lynx is to apply a heuristic that assumes that every space was supposed to have been a %20. This won't work if multiple spaces got coalesced, extra spaces get introduce to improve layout, or the URL got wrapped and the space was turned into a newline. In the latter case you have a choice of at least three heuristics: 1) treat newline as a space and encode as %20; 2) treat newline as CR-LF and encode as %0d%0a (or %0d or %0a or %0a%0d...); 3) assume, that, unlike the space, the newline wasn't really supposed to be there (possibly the best strategy for URL massacred by GUI email programs, and the most compliant one). As even the space means %20 rule is an error recovery heuristic, it needs to be an option that can be turned off, to produce more compliant but less pragmatic, behaviour. Note that the extract from the URL specification is saying how URLs should be written, not how they should be sent in HTTP requests. ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
