[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: R: RE: Re: Help on http_url_post() procedure
hi Eugenio,
With regard to adding the XML directly onto the URI... that's perfectly
valid, and if that solves your problem, great. However, why bother with
a POST request in that case? You aren't sending any POST data, so I
would recommend using a GET request instead.
Also, be aware of the maximum possible length of a URI. There is no
documented maximum, but different browsers and servers have set
different maximums... Here's some research that has been done:
http://www.boutell.com/newfaq/misc/urllength.html
Note that yours is 1024, and if that (or even double that, 2048) is
large enough for any possible values in your XML document, then this
method will probably work okay for you. However, notice that when you
exceed 2048 you quickly hit compatibility issues... Internet Explorer
only allows 2048. Apache only allows 4000. It gets ugly quickly.
Although HTTPAPI allows 32767, I personally think that when your URI
exceeds 2048 chars, you have a major design problem. You shouldn't
encode the data into the URI if you need it to be longer than 2k.
That's why most web services use POST instead of GET, and send their
parameters in the POST data rather than incorporating them into the URI.
I don't know if your web service allows this or not? But it is the
normal way of doing things in the industry as a whole. POST data has
no effectively limit in size.
Your example below (where you set the content-type) makes no sense to
me. Your data appears to be a URL-encoded XML document, but you've told
the HTTP server that it's an ASCII encoded HTML document. Whaaat?? How
can you expect that to do anything except confuse the HTTP server?
Please try setting your form data to application/x-www-form-urlencoded
-- that's what a browser would use.
On 8/17/2010 3:33 AM, edlp1950@xxxxxxxxx wrote:
> Hi Mike,
> thank you for your answer and your suggestions.
> I think a POST request will work too.
> In my example the size of 1024 is large enough, but probably in the real
> application I will work with much larger document.
> It's because I'm still trying to use POST and to access encoded URL parameters
> by pointer.
>
> Before using GET method, I tried Scott's suggestion to include the content-
> type in http_url_pos call.
> Here is the modified source.
>
>
> D/copy qrpgcopy,httpapi_h
>
> D cmd pr extpgm('QCMDEXC')
> D command 200A const
> D length 15P 5 const
>
> D enc s like(HTTP_URL_ENCODER)
> D pointer s *
> D size s 10I 0
> D xml s 1024a varying
> D content_type s 64a inz('text/html;charset=ISO-8859-1')
> <--- I also tried 'text/xml'
>
> D RESPONSE c const('/tmp/response.xml')
> D TRACE c const('/tmp/trace.txt')
> D CRLF c const(x'0D25')
> D HYP c const(x'7D')
> D URL c const('http://xxx.xxx.xxx.xxx:
> 8080/axis2/WebService')<--- I also tried with a question mark at the
> end
> D OK c const(1)
>
> /free
>
> xml = . . .;
> http_setccsids(HTTP_ASCII:HTTP_EBCDIC);
> http_debug(*ON:TRACE);
>
> enc = http_url_encoder_new();
> http_url_encoder_addvar(enc:'data' : %addr(xml)+2 : %len(%trimr(xml)));
> http_url_encoder_getptr(enc : pointer : size);
>
> if http_url_post(URL:
> pointer:
> size:
> RESPONSE:
> HTTP_TIMEOUT:
> HTTP_USERAGENT:
> content_type) = OK;
> cmd('DSPF ' + HYP + RESPONSE + HYP : 200);
> endif;
>
> *inlr = *on;
> return;
>
> /end-free
>
>
> Here is the trace of the call.
> I hope you can find in it some information about my errors.
>
>
> HTTPAPI Ver 1.23 released 2008-04-24
> OS/400 Ver V6R1M0
>
> http_url_post(): entered
> http_persist_open(): entered
> http_long_ParseURL(): entered
> DNS resolver retrans: 2
> DNS resolver retry : 2
> DNS resolver options: x'00000136'
> DNS default domain: myDomain
> DNS server found: xxx.xxx.xxx.xxx
> DNS server found: xxx.xxx.xxx.xxx
> http_persist_post(): entered
> http_long_ParseURL(): entered
> do_post(): entered
> POST /axis2/WebService HTTP/1.1
> Host: xxx.xxx.xxx.xxx:8080
> User-Agent: http-api/1.23
>
> Content-Type: text/html;charset=ISO-8859-1
> Expect: 100-continue
> Content-Length: 704<------- that's because I think size of "xml" is enough
> for this test
>
> recvresp(): entered
> HTTP/1.1 100 Continue
>
> SetError() #13: HTTP/1.1 100 Continue
> senddoc(): entered
> data=%3CWebRequest+Version%3D%221.0%22%3E%3C . . .<---- I can read the entire
> document in encoded version
> recvresp(): entered
> HTTP/1.1 200 OK
> Server: Apache-Coyote/1.1
> Content-Type: text/html;charset=ISO-8859-1<------ I think that's the
> content type web server expects and I set the same value in my call
> Transfer-Encoding: chunked
> Date: Tue, 17 Aug 2010 07:16:23 GMT
>
> SetError() #13: HTTP/1.1 200
> OK
> recvdoc parms: chunked
> 0
> header_load_cookies()
> entered
> recvchunk():
> entered
> get_chunk_size():
> entered
>
> bc
>
>
> chunk size =
> 188
> get_chunk_size returned
> 188
> calling
> comm_blockread
> <?xml version="1.0" encoding="UTF-8"?> <WebResponse Version="1.0" RtnCode="KO"
>> <error>java.lang.NullPointerException</error> </WebResponse>
> comm_blockread returned
> 188
>
>
> get_chunk_size():
> entered
>
> 0
>
> chunk size = 0
> get_chunk_size returned 0
> http_close(): entered
>
> I restored current BETA version of HTTPAPI to see examples you suggest.
> Thanks again.
> Eugenio
>
>> ----Messaggio originale----
>> Da: mkrebs@xxxxxxxxxxxxxxxxxx
>> Data: 17-ago-2010 1.34
>> A: "HTTPAPI and FTPAPI Projects"<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
>> Ogg: RE: Re: Help on http_url_post() procedure
>>
>> Your test POST appears to show that a POST will work. Just have to get it
> right in HTTPAPI. But the format of web service appears to prefer GET? It is
> possible that both will work.
>>
>> You coded the size of XML to be 1024. Is that the maximum size? Your "target"
> should be somewhat larger. Encoding can really add characters (the encoded
> characters will be 3 times as big as unencoded characters -- not all characters
> get encoded).
>>
>> There is a practical limit (although not in the RFC) on the size of the GET
> request (using URL with parameters). HTTPAPI limits this to 32K if you are
> using http_url_get. Your web service provider might also have a limit (depends
> on the server they are using) and should be aware of the number. If the XML
> could be large, use POST instead.
>>
>> Encoding into a string has a practical limit (32k of encoded data in current
> beta). Encoding using pointer allows much larger XML. Again a design decision
> and how you are going to be using the data.
>>
>> As far as making your HTTPAPI POST example work, try Scott's suggestion to
> include a content type. It would appear you can use EXAMPLE4 in the current
> beta as an example. Depending on the real length of your xml you may want to
> just encode it yourself instead of using the webform. Use an appropriate type
> in the seventh parameter of the post. "text/xml" maybe?
>>
>> Maybe you could wireshark your post request and see what was being sent or
> find out what is different between httpAPI and your post example.
>>
>>> Can I process directly a stmf? (I thought I could use
>>> http_url_post_stmf(),
>>> but now I know I've to use GET method)
>>
>> I believe EXAMPLE7 in current beta will be your ticket. Look it over and you
> see various forms of IFS handling being used.
>>
>> Good luck,
>> Mike Krebs
>>
>>
>>> -----Original Message-----
>>> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
>>> bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of edlp1950@xxxxxxxxx
>>> Sent: Monday, August 16, 2010 4:56 AM
>>> To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
>>> Subject: R: Re: Help on http_url_post() procedure
>>>
>>> Hi Scott,
>>> first of all I want to thank you for your answer and for your help.
>>>
>>> I tried to get more information from the web server administrators, but
>>> I
>>> don't succeded in that.
>>> They said I've only to do a POST request like this:
>>> http://xxx.xxx.xxx.xxx:8080/axis2/WebService?data=xml message
>>>
>>> However I modified my sorce as you suggested, sending my document by
>>> GET
>>> instead of POST.
>>>
>>> D/copy qrpgcopy,httpapi_h
>>>
>>> D cmd pr extpgm('QCMDEXC')
>>> D command 200A const
>>> D length 15P 5 const
>>>
>>> D enc s like(HTTP_URL_ENCODER)
>>> D xml s 1024a varying
>>> D target s 1024a varying
>>>
>>> D RESPONSE c const('/tmp/response.xml')
>>> D TRACE c const('/tmp/trace.txt')
>>> D CRLF c const(x'0D25')
>>> D HYP c const(x'7D')
>>> D URL c
>>> const('http://xxx.xxx.xxx.xxx:8080/+
>>> D axis2/WebService?')
>>> D OK c const(1)
>>>
>>> /free
>>>
>>> xml = . . . ;
>>> http_debug(*ON:TRACE);
>>>
>>> enc = http_url_encoder_new();
>>> http_url_encoder_addvar(enc : 'data' : %addr(xml)+2 :
>>> %len(%trimr(xml)));
>>> target = URL + %trim(http_url_encoder_getstr(enc));
>>>
>>> if http_url_get(%trim(target) : RESPONSE) = OK;
>>> cmd('DSPF ' + HYP + RESPONSE + HYP : 200);
>>> endif;
>>>
>>> *inlr = *on;
>>> return;
>>>
>>> /end-free
>>>
>>> Great! Now WebService returns the response I expect!
>>> Thanks a lot Scott!
>>>
>>> But now I have some questions.
>>>
>>> 1. why they said I had to send XML document by POST method?
>>> In my "HTML simulator" I wrote "<form action="http://xxx.xxx.xxx.xxx:
>>> 8080/axis2/WebService" method=post>"
>>>
>>> 2. in some example you say http_url_encoder_getstr() is slower than
>>> http_url_encoder_getptr().
>>> Is it possible to use the second one? Do you suggest to do that?
>>>
>>> 3. In the application we're developing, I'm required to store xml
>>> document
>>> (sent and received) in IFS.
>>> I think I have to compose xml as a string, store it as IFS stmf and
>>> send it
>>> after encoding.
>>> In this way i'm sure that what I send and what I store are two
>>> different
>>> things.
>>> There is a better way to do that?
>>> Can I process directly a stmf? (I thought I could use
>>> http_url_post_stmf(),
>>> but now I know I've to use GET method)
>>>
>>> Any other suggestion is welcome.
>>> Thanks a lot again.
>>> Eugenio
>>>
>> -------------------------
>> -----------------------------------------------------------------------
>> This is the FTPAPI mailing list. To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> -----------------------------------------------------------------------
>>
>
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------