From 637909614b5d4726a5069ba94b85ca26ebbe0bf1 Mon Sep 17 00:00:00 2001 From: jocelyn Date: Tue, 2 Aug 2011 07:31:08 -0700 Subject: [PATCH] Updated EWSGI: open questions (markdown) --- EWSGI:-open-questions.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EWSGI:-open-questions.md b/EWSGI:-open-questions.md index a494a915..eeb2d2ac 100644 --- a/EWSGI:-open-questions.md +++ b/EWSGI:-open-questions.md @@ -6,17 +6,17 @@ 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 ) +- **parameters** (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_fields** (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. -- input data ... +- **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