[Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7) (original) (raw)
Bill Janssen janssen at parc.com
Mon Apr 20 17:32:52 CEST 2009
- Previous message: [Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
- Next message: [Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Antoine Pitrou <solipsis at pitrou.net> wrote:
Bill Janssen <janssen parc.com> writes: > > Sure. But nowhere does a spec say that this page charset should be used > in sending the values of a FORM using application/x-www-form-urlencoded > in a new HTTP request. It's just a convention some browsers use.
Let's call it a de facto standard then. A behaviour doesn't have to be engraved in an RFC to be considered standard.
Sure. And if HTTP was all about browsers keying off pages, that would be fine with me. But it's not. HTTP is used in lots of places where there are no browsers; in fact, the idea we're busy bike-shedding is all about a client-side library making calls on a server. It's used in places where there are no "pages", too, just servers on which clients are making REST-style calls. So in the real world, the only way in which you can reliably post non-ASCII values to a server using HTTP is with multipart/form-data, which allows you to explicitly say what character set you are using. I've debugged this problem too many times with REST servers of various kinds to think otherwise.
Bill
- Previous message: [Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
- Next message: [Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]