µTasker Forum
µTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: chronosdino on October 23, 2008, 01:47:01 PM
-
Hi,
i have seen that the post methos is operational on µTasker.
However, i want to send data in the memory.
I want to know where and what a have to change or adapt in the µTasker code for using it.
My webpage is thisone :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html Lang="fr">
<head>
<meta http-equiv="Pragma" content="no-cache" charset=ISO-8859-1>
</head>
<FORM action="upload.html" name="form2" method="post" enctype="multipart/form-data">
<INPUT type="file" name="file2">
<INPUT type="submit" value="send2">
</FORM>
<p><a href="dl.dat" type="application/x-octet-stream" action= "dl.dat"><b>Downloading configuration</b></a><br>
</html>
i want to write the file in a special memory block
for exemple : from 0x10000 to 0x12000
thank you for the time that you take for me !
Chronos_dino
-
Hi
Yes, the post method is supported. Posting parameters and/or files is possible.
Your example shows the file posting method being used, so you can use the firmware upload in the uTasker demo project as reference.
You need to activate SUPPORT_HTTP_POST for the basic support to be enabled. To accept binary files you need SUPPORT_POST_BINARY, for text you need SUPPORT_POST_TEXT
The thing to remember is that you can either post to a file (similar to transferring a file via FTP) or you can post to the application (see fnHandleWeb() in the demo project to see how the application handles the events CAN_POST_BEGIN, INFORM_POST_FAILED and INFORM_POST_SUCCESS.
This is controlled by the posted name - eg.:
<form action=HS.bin means POST to the file "H.bin" - the file will be stored there, and serve the page "S.html" on completion
<form action=B0.gif means POST to the file "B.gif" - the file will be stored there, and serve the page "0.html" on completion
The application can still decide to cause a different page to be served if desired.
<form action=*S.bin is special since it means that the file content should be passed to the application for handling (special character *), rather than saving to the file system. For this to work, the configuration SUPPORT_HTTP_POST_TO_APPLICATION should be set.
In this case the application will receive the event POSTING_DATA_TO_APP on each frame received, where
http_session->cDisplayFile is 'S' in this example and will cause this file to be served on completion, if not changed by the application, but can also be used to distinguish between various different application posts.
http_session->FileLength is the length of the present data frame being received
*ptrData is a pointer to the present frame being received,
The technique of posting to the application is useful when the posted file is not to be saved to the file system (FLASH) but rather be handled by the application, which may parse its content or sent to on to another post - like UART, I2C, SPI, CAN, USB etc.
I don't think that the demo project actually has an example of this (at the moment) but it is best to experiment using the uTasker simulator since these events can then be easily analysed and new code developed.
Regards
Mark
-
Hi
Here are few additional tips about handling POST to a web server.
1. Use WireShark to view the POST that is being received to be sure that the type is known. For example if text based content is being received the POST header will contain the content type "text/plain".
2. Ensure that the type is supported by the HTTP server - for example
#define SUPPORT_POST_TEXT
will ensure that it recognises the type and not ignore it.
3. When a recognised/supported POST content type is received the application callback will be called with the event type CAN_POST_BEGIN and the application level can decide whether it wants to accept (return 0) it or ignore it (return 1). Ignored posts will be silently discarded but the transfer is allowed to take place (to nowhere).
4. POST content is either saved to file or passed to the application (on a TCP frame basis).
Posts that are saved to file report success at the end with the callback event INFORM_POST_SUCCESS or INFORM_POST_FAILED.
Posts that are handled by the application layer pass each TCP frame's payload using the event POSTING_DATA_TO_APP and the application uses the content for whatever purpose it chooses - for example it can also save it to a file or interpret its content as it arrives. The final events INFORM_POST_SUCCESS or INFORM_POST_FAILED again signal the end of the complete post content.
5. Plain text post content is usually handled by POSTING_PARTIAL_PARAMETER_DATA_TO_APP and POSTING_PARAMETER_DATA_TO_APP event (POSTING_PARTIAL_PARAMETER_DATA_TO_APP indicates a fragment of a larger plain-text post and POSTING_PARAMETER_DATA_TO_APP indicates either a complete one in a single frame or the last in a larger post. This is typically used for passing parameters (like JSON strings) where the application will parse the content to extract the values (in the case of partial frames it may need to add buffering so that it can collect complete parameters before interpretation is possible).
See fnHandleWeb() in webInterface.c in the uTaskerV1.4 project for some reference handling of the events.
It is recommended to use the simulator to test such transfers, where a break point in fnHandleWeb() allows each event and accompanying data packet to be analysed.
Regards
Mark