I have used HttpConnection in J2ME for communication between server. I want to send some data to server with http header. Can anybody tel me how to set header information with HttpConnection. Any example.
Thanks
From http://www.j2mesalsa.com/elearning/networking.html :
Set Header Information
To set request header properties use setRequestProperty(String key, String value).
Example:
setRequestProperty( "User-Agent", "Profile/MIDP-1.0 Configuration/CLDC-1.0" )
Hope it helps.
Related
Is there a way to set webhook headers by code?
I'd like to send an authorization header to the fulfillment webhook but I need to set it dynamically from code (using nodejs)
At the moment my headers are empty.
Currently, you could pass a header via webhookHeaders of the QueryParameters object. It's available from v2beta1 version. Check it out https://cloud.google.com/dialogflow/docs/reference/rest/v2beta1/QueryParameters
This has me baffled.
I can request the document content as base64 with curl , no problem.
curl https://demo.docusign.net/restapi/v2/accounts/<id>/envelopes/<id>/documents<id> -H"Authorization : Bearer <token>" -H "Content-Transfer-Encoding: base64" -o <filename>
Return headers are
Content-Disposition: file; filename="blah"; documentid="1"
Content-Transfer-Encoding: base64
and the file is returned in base64 format.
Using the Apache oltu oauth2 library which underneath uses HttpURLConnection I cannot get the response to be sent in base 64. I have the request headers set to
Content-Transfer-Encoding: base64
Accept : */*
Authorisation : Bearer <token>
But all I ever get back is the binary version of the file which ultimately bombs out because the library saves the stream as a string which screws up the pdf.
I can't trace the return header , but the request header definitely has the above fields set.
Is there anything in the Docusign endpoints which look at the User-Agent or anything else to determine whether to do the base 64 encoding ? Why else would it only ever return the binary stream ?
I suspect your Java output is not the same and the best way to confirm this is to capture exact JSON/SOAP request posted by your API calls via Java to DocuSign by following steps explained at this DocuSign support article https://support.docusign.com/guides/ndse-user-guide-api-request-logging
Please post these and I am sure it will be we will be able to deduce the library "add" that is changing the actual output.
OK thanks #david for the advice on logging the requests in docusign. I find that the "Transfer-Content-Encoding" header has mysteriously disappeared on arrival at the Docusign server. Some digging indicates that
a. this header is dodgy anyway for non-email uses and that
b. in the Java HttpUrlConnection class it is "removed" as security measure. You can apparently set some flags to revert to previous behaviour. See https://bugs.openjdk.java.net/browse/JDK-6996110
In any case I worked around the problem by implementing a class which reads the response as an InputStream and not worrying about base64.
Hopefully this helps a Java OAuth library user save a day of their lives banging their heads against a wall !
In my XPages application I want to keep the connection alive when sending a XMLHttpRequest from one XPage to another. Therefore, I set the "Connection" header to "keep-alive".
On the client-side I have:
xhr=new XMLHttpRequest();
xhr.setRequestHeader("Connection","keep-alive");
and on the server-side (in the afterRenderResponse event of the responding XPage) I use:
response=facesContext.getExternalContext().getResponse();
response.setHeader("Connection","keep-alive");
When inspecting the request and the response (with FireBug), it turns out that the request headers contain "Connection = keep-alive" (as expected), but the response headers contain "Connection = close".
Does anybody know how to override this header?
SOLUTION: In the xsp.properties file set xsp.compress.mode=gzip. This is equal to setting Compression = "GZip, set content length" under Xsp Properties / Page Generation.
EXPLANATION: My application used the server default for compression, which is gzip-nolength. When the content length is not set, the XPages' response (XspHttpServletResponse) seems to always set the "Connection" header to "close". After setting the content length the "Connection" header is no longer present and the connection is kept alive by default.
I can not for the life of me find any documentation regarding the possible properties of varnish (version 3) objects.
We know (from googling, varnish documentation just mumbles and leaves you more frustrated) for example that the request object has the url property (req.url) and also that it has req.http.X-Forwarded-For. But has anyone ever in any way found... say... a list?
Thanks!
/joakim
You can't really give a comprehensive list of things like req.http.X-Forwarded-For because req.http.* are HTTP headers. The Cookie header of a request will be req.http.Cookie and the User-Agent header will be req.http.User-Agent. There are a lot of standard headers, but you can set any arbitrary header and it will show up in req.http.___________. You can see the headers of the HTTP response in resp.http.*. Same for backend response in beresp.http.*.
All of the other properties are listed here: https://www.varnish-cache.org/docs/3.0/reference/vcl.html#variables
I'm building a client for an api that uses http digest access authentication for authentication. I have studied the rfc to know the setup the required response headers and this works well on my emulator. Problem however is when I test on my phone (nokia E5), I found out that getting the www-authenticate header from the returned headers doesnt get the full value
[code]
// c = (HttpConnection) Connector.open(url) and other declarations
String digest = c.getHeaderField("WWW-Authenticate");
System.out.println(digest); // gives only: Digest
//no realm, qop and others
[/code]
I'm I doing something wrong or it is from the phone? What are my other options?
I have faced this problem in some nokias, and yes, it is a bogus HttpConnection implementation ... I suggest you to try creating a new header from the server side with a base64 encoded WWW-Authenticate-encoded header and using it instead, or you can do it the hard way and implement the whole HttpConnection from scratch ...