Closed GoogleCodeExporter closed 9 years ago
Original comment by loentar
on 6 Sep 2013 at 5:01
I made some research.. Looks like Axis2/c does not have any method to control
outgoing http headers.
This issue can't be fixed without modifying of Axis2/C itself.
If you know any method to do it without Axis2/C modification, please say.
One thing I can suggest, use CURL-based transport and look into
https://issues.apache.org/jira/browse/AXIS2C-1612.
Original comment by loentar
on 16 Nov 2013 at 10:47
I've found a method to add http headers, but I've got stuck in the middle
because the operational context (op_ctx) is not accessible when calling
axis2_op_client_get_operation_context(), throwing a SIGSEGV. This is how far I
reached... some insight, please?
axis2_svc_client_t * cl = NULL;
cl = (axis2_svc_client_t *) aService->GetClient();
axutil_env_t * env = staff::Runtime::Inst().GetAxis2Env();
axis2_op_client_t * opc = axis2_svc_client_get_op_client(cl, env);
axis2_op_ctx_t *opctx = axis2_op_client_get_operation_context(opc, env);
axis2_msg_ctx_t * ctx = axis2_op_ctx_get_msg_ctx(opctx, env,
AXIS2_WSDL_MESSAGE_LABEL_OUT);
axutil_array_list_t * headers = NULL;
axutil_array_list_create(env, 1);
axis2_http_header_t * http_header = axis2_http_header_create(env,
"header_name", "header_value");
axutil_array_list_add(headers, env, http_header);
axis2_msg_ctx_set_http_output_headers(ctx, env, headers);
Original comment by pedro.me...@gmail.com
on 21 Nov 2013 at 7:36
The working method will be used in client api:
axis2_options_t* ops = *m_pOptions;
axutil_array_list_t* headers = axutil_array_list_create(m_pEnv, 1);
axis2_http_header_t* http_header =
axis2_http_header_create(m_pEnv, "header_name", "header_value");
axutil_array_list_add(headers, m_pEnv, http_header);
axis2_options_set_http_headers(ops, m_pEnv, headers);
Original comment by loentar
on 21 Nov 2013 at 8:31
Example of use:
staff::Options& rOptions = tClient.GetOptions();
rOptions.AddHttpHeader("Header1", "Some value for header 1");
rOptions.AddHttpHeader("Header-2", "Some value for header two");
Original comment by loentar
on 21 Nov 2013 at 8:51
This issue was closed by revision r809.
Original comment by loentar
on 21 Nov 2013 at 8:53
Current mechanism is not safe, because list of headers will be deleted after
client request, and client gets SIGSEGV on second request.
Also, new API is a little more convenient:
staff::Options& rOptions = tClient.GetOptions();
staff::StringMap httpHeaders;
httpHeaders["customHeader1"] = "value of header 1";
httpHeaders["customHeader2"] = "value of header 2";
httpHeaders["SomeOtherHeader"] = "111";
rOptions.SetHttpHeaders(httpHeaders);
Original comment by loentar
on 26 Nov 2013 at 7:09
Original issue reported on code.google.com by
pedro.me...@gmail.com
on 6 Sep 2013 at 1:33