Opened 11 years ago

Last modified 10 years ago

#40 new defect

Implementation advice on creating IRI query strings from HTML forms

Reported by: duerst@… Owned by:
Priority: major Milestone:
Component: iri-processing Version:
Severity: - Keywords:


The percent-encoding handling of query components in the HTTP scheme is really unfortunate. There is no good normative advice to give if the percent-encoding is delayed until the query-IRI is interpreted. Could HTML ask browsers to percent-encode the form data using the document character set BEFORE the query IRI is constructed, and only in the case where the document character set isn't Unicode-based and the query is being added to http: or https: URIs? This would give more consistent results. Browsers might have to change their behavior in constructing the IRI-with-query-added, but the results would be more consistent and fewer bugs, and it wouldn't affect interpretation of any existing web pages. It would remove the need to have a normative special case for queries in HTML documents, just for http, in a way in which things like transcoding etc. wouldn't work well. You could tell the difference between a query URI in the address bar and one created via a form because the address bar would always be UTF-8. The browsers might have to change the algorithm for showing the address in the adress bar to know how to undo the encoding.

Change History (1)

comment:1 Changed 10 years ago by masinter@…

  • Component changed from 3987bis to iri-processing
  • Summary changed from Implementation advice on handling query strings to Implementation advice on creating IRI query strings from HTML forms

The advice I was suggesting here really is for changing how browsers construct IRIs based on form data entry, in order to remove ambiguity for downstream processors, by leaving the IRIs constructed as %xx encoded.

If that happened, we might then be able to note this in the 3987bis as well, after this is resolved in the processing spec.

Note: See TracTickets for help on using tickets.