From d0576c6829c8284ec9bd4cfc4c7a41c029bba4b9 Mon Sep 17 00:00:00 2001 From: jocelyn Date: Mon, 5 Sep 2011 06:03:33 -0700 Subject: [PATCH] Updated EWSGI Open Questions (markdown) --- EWSGI-Open-Questions.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/EWSGI-Open-Questions.md b/EWSGI-Open-Questions.md index eeb2d2ac..d6958f94 100644 --- a/EWSGI-Open-Questions.md +++ b/EWSGI-Open-Questions.md @@ -6,19 +6,20 @@ And then for Berend, STRING_32 is not the solution. Most of the data are just STRING_8 in CGI so let's list the various request data -- **parameters** (from the query string ?foo=bar&extra=blabla ) +- **query_parameter** (from the query string ?foo=bar&extra=blabla ) in this case, I think the name can be url-encoded, and obviously the value too I guess it makes sense to url-decode them but on the other hand, we could just keep them url-encoded (as they are), and it is up to the application to url-decode them if needed. Of course, we should provide facilities to url-decode those strings. -- **form_fields** (from the POST method) +- **form_data_parameter** (from the POST method) quite often, it is same kind of content that `parameters' but .. here this might depends on the encoding for multi-parts encoding. +- **meta_variable** (from the request itself ... CGI meta variables..) + I am wondering about unicode domain name ... + - **input data** ... I think this is up to the application -note: that form fields sent by GET method, will be in `parameters' ... so maybe we should rename the "form_fields" as "post_parameters". Anyway not critical for now - ... to be continued ...