Re: Luasocket 2.0: socket.http.request using POST

[LEGO <luis.ontanon@...>]

On 2/7/06, Diego Nehab <diego@tecgraf.puc-rio.br> wrote:
> Hi,
>
> I wouldn't call this a bug. It is a feature request. A bug is something
> that behaves differently from specification.
I agree that a SHOULD is not a MUST but still believe that SHOULDs
should be implemented unless there is a specific reason not to, but
then again it's just my personal opinion, it is juat a SHOULD not a
MUST.


> The simple API simply does not support the definition of a content-type
> header (call it oversight).
> The content-length header is a completely
> different story. It *has* to be there.
for compatibility with HTTP/1.0 yes it has to, but in HTTP/1.1 it does
not not necesarily have to be there, in some  are cases in it MIGHT or
MUST NOT not be there (4.4 explains when) and the RFC implicitly tells
that in some parts it  should not be used.

RFC 2116 is somewhat hard to understand, It MAY not be ambiguous, but
it SHOULD certailnly be clearer :-).

But it in 14.13 it clearly says
"
  ... In HTTP, it  SHOULD be sent whenever the message's length can be
determined prior
   to being transferred, unless this is prohibited by the rules in
   section 4.4.
"

> When I wrote the code, the most
> popular servers did not accept accept chunked posts. Besides it is *not*
> ambiguous at all. Content-type, on the other hand, is ambiguous.

I think it SHOULD give a Content-Type: so the server knows what's
there, and does not need to guess. But that's my personal opinion.

Then RFC2616 tells in p3.7
"
   Note that some older HTTP applications do not recognize media type
   parameters. When sending data to older HTTP applications,
   implementations SHOULD only use media type parameters when they are
   required by that type/subtype definition.
"

> Why should I define it as being application/x-www-form-urlencoded
> instead of, say, multipart/mixed? Is it really more common?

That's a Presentation layer issue not certainly a Session layer one so
HTTP (been L5 protocol) is not realy involved with that. I would say
let's see if MIME tells us what to do but guess... p 19.4.1 tells that
"HTTP is not a MIME-compliant protocol" so in our case it does not
apply.

So that's preety much an implementors issue, many ITU-T standards
define the interoperation between layes the HTTP/1.1 RFC does not. It
does not specify what SAP (service access points) one module has to
provide to another one and how that interface is proved.

In the HTTP field there is the CGI specification (
http://hoohoo.ncsa.uiuc.edu/cgi/ ) that provides that but it does not
apply to this case. So you are free to implement it as you want.

I would use application/x-www-form-urlencoded as it's more common
unless you want to transfer files in which case RFC1867 might be more
apopriate.

But anyway I still believe (an Opinion Report if you want to consider
it that way) that a Content-Type should be provided.

Luis.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan