HTTP method for POST query argument

Frederic Bregier fredbregier at free.fr
Sun Sep 6 05:48:05 EDT 2009


Hi Trustin,

I know that I wrote I will not send a new version, but as I made a lot 
of improvement and finally get the encoder to work, I decide to post 
this primary work.

Here are the changes:
- Change HttpBodyRequestXXX to HttpPostRequestXXX since in fact it does 
only encode or decode Post Body requests.

- I made Attribute also compatible with a Memory or Disk or mixed mode 
as FileUpload.
  The reason is that in POST form a TEXTAREA could be huge (like a paste 
of a file) so useful to be on disk.

- I keep the memory for both Attribute (obvious since generally the 
case) and for FileUpload.
  The reason is that in some case, even writing on files could be a 
problem for a web server (not enough disk).
  And as you wrote before, other implementations can occur (webdav, 
database, ...).
  For one of my project, my implementation will be a passthrough object 
(not stored but passed to the next network protocol by chunk).
  A cleanFiles method allows to clean temporary files (if any).
 
- I finally made a first implementation of the HttpPostBodyEncoder.
  It follows globally the same idea from Decoder except it will change 
the request header accordingly to multipart or not and the final size of 
the body.
  It tries to be optimized (more is still possible) in term of memory by 
reusing HttpData object.
  It is possible to get back the list of HttpDatathat were set into one 
encoder for another one.
  It was not so easy since it is quite more complicated than decoder...

  The global idea is:
  - create an HttpRequest
  - create an HttpPostRequestEncoder from the request and a boolean for 
multipart or not, setting optionally the factory
  - fill the request with the header or cookie
  - fill the encoder with the Attribute or FileUpload
  - call encoder.finalizeRequest()
  - writing the request to the channel (also returned by the 
finalizeRequest in case)
  - testing if the request is a chunked one
  - if so
    - getting the nextChunk from encoder (chunk = 
encoder.encodeNextChunk();) and write it to the channel
    - if this is the last chunk, stops, else get the nextChunkfrom 
encoder again until end
  - once all done, the user can call encoder.cleanFiles() if the list of 
HttpData is no more useful (so the reason it is not automatic).
 
- I made a client example that simulate the natural browser example that 
were in the previous example.
  So one can test the server example directly using his/her own browser 
or the client that simulates the post of the three forms (get, post not 
multipart, post with multipart).
  Of course reading the example will help to know how to use it.
 
I hope it is still ok and correct from your point of view.

The next step should be first reviewing the AggregateChannelBuffer to 
enhance the Component version if OK.
Then if this work is OK too, I will enhance the doc in API to include 
some extra information in the header of the API for the encoder and the 
decoder (to not rely only on example).
And finally, if all is OK, I could publish the work as a replacement of 
http current codec (I would renaming http2 to http and replace Aggregate 
by Component).
So there are still some work to do. ;-)

I try to join the zip in the mail (the website of Jboss is unresponsive).

Cheers,
Frederic 

 

-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/HTTP-method-for-POST-query-argument-tp3457351p3591948.html
Sent from the Netty Developer Group mailing list archive at Nabble.com.


More information about the netty-dev mailing list