Updated EWSGI Open Questions (markdown)

This commit is contained in:
jocelyn
2011-09-05 06:03:33 -07:00
parent 060f1482fe
commit d0576c6829

View File

@@ -6,19 +6,20 @@ And then for Berend, STRING_32 is not the solution.
Most of the data are just STRING_8 in CGI Most of the data are just STRING_8 in CGI
so let's list the various request data 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 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 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. 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. 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' quite often, it is same kind of content that `parameters'
but .. here this might depends on the encoding for multi-parts encoding. 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** ... - **input data** ...
I think this is up to the application 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 ... ... to be continued ...