[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SV: AW: proxy access problem

From: Julius Kaj <Kaj.Julius@xxxxxx>
To: "'HTTPAPI and FTPAPI Projects'" <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: SV: AW: proxy access problem
Date: Thu, 8 Sep 2016 09:36:53 +0200
You haven't really explained your proxy all that well, but...
https://en.wikipedia.org/wiki/Proxy_server


My best guess would be that you'll need your forward proxy to employ some sort of URL rewrite to replace app-proxy.eb.lan.at:10071 with secure.armstrongconsulting.com. I'm guessing, it's the proxy that needs an additional rule added, rather than you needing to tweek your web service program.


-----Oprindelig meddelelse-----
Fra: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] På vegne af Alexander Grünwald
Sendt: 7. september 2016 21:17
Til: HTTPAPI and FTPAPI Projects
Emne: AW: AW: proxy access problem

Hello Scott,

yes, that´s what I would like to have. Due to security rules, our System i may not connect directly to a server outside the whole environment. So there is a server app-proxy.eb.lan.at that offers a port. This port forwards our requests to a fixed endpoint. So the setting is: port 10071 forwards to secure.armstrongconsulting.com:443.
This works great for other partners with similar settings (also https), but with this partner we have the problem, that the host header would not have the correct value, if I do not use http_setproxy(). This procedure helps me connect tot he app-proxy.eb.lan.at and keep the original host value - fine. Nevertheless I do not get a connection tot he endpoint.
I am uncertain, if this "forwarding" is similar to the standard process of a proxy and if HTTPAPI is expecting a response from such a proxy.

Generally communication tot he endpoint works. Packets are transferred tot hem, but they refuse to answer due tot he RFC2616 rules.

Maybe I can manipulate the host-value oft he communication. I have seen, there is a procedure to add values tot he header, but I cannot exchange values oft he header.

Hope I could explain things a little bit better.
 

Mit freundlichen Grüßen/Best regards Mag. Alexander Grünwald

-----Ursprüngliche Nachricht-----
Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Scott Klement
Gesendet: Mittwoch, 7. September 2016 20:27
An: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Betreff: Re: AW: proxy access problem

Alexander,

I'm sorry, I don't understand what you are asking.

Are you saying that you want HTTPAPI to connect to
app-proxy.eb.lan.at:10071 and send it the request as if it were the 
end-point rather than a proxy?   But, you still want the host: header to 
point to secure.armstrongconsulting.com?

That doesn't seem like it would be secure.  But, I'm not certain that I understand correctly, so please clarify.

-SK


On 9/7/2016 4:52 AM, Alexander Grünwald wrote:
> Hello !!
>
> Some additional information regarding this issue. It seems that the proxy_tunnel procedure has a problem, when waiting for proxy´s response. As this "proxy" is a forwarding proxy, which knows that every tcp-packet, I send to "app-proxy.eb.lan.at:10071" has to be forwarded directly to the https-port (443) of "secure.armstrongconsulting.com", I am uncertain, if I am using the proxy approach correctly. It seems, I won´t get any response from my poxy directly which ends in -1 when receiving and parsing proxy server's response in procedure proxy_tunnel.
>
> Any ideas ?
>
> Thanks a lot, Alexander
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
> -------------
>
> Hi Scott,
>
> as announced earlier, I am actually testing access to a testserver via proxy.
> The situation in our environment is as following:
>
> -        We may not access any server outside the network directly.
>
> -        Therefore we have a proxy server and a port number to use
>
> -        Sending web-service requests to the proxy as host-url with the portnumber (https://app-proxy.eb.lan.at:10071) forwards our request to the destination host (works fine generally and we are using this approach for several years with other partners)
>
> -        Unfortunately our new partner wants to ensure RFC2616 conformity and checks the host header: when we send out our request using the proxy setting, we use as host the final destination (https://secure.armstrongconsulting.com/) and use http_setproxy('app-proxy.eb.lan.at':10071), the communication doesn´t work. What am I missing here ?
>
> Enclosed is the debug log for my proxy access:
>
> HTTPAPI Ver 1.32 released 2016-02-10
> NTLM Ver 1.4.0 released 2014-12-22
> OS/400 Ver V7R1M0
>
> New iconv() objects set, PostRem=819. PostLoc=0. ProtRem=819. 
> ProtLoc=0
> http_setauth(): entered
> https_init(): entered
> QSSLPCL = *OPSYS
> SSL version 2 support disabled
> SSL version 3 support enabled
> Old interface to TLS version 1.0 support enabled TLS version 1.0 
> support enabled TLS version 1.1 support enabled TLS version 1.2 
> support enabled
> ----------------------------------------------------------------------
> --------------- Dump of local-side certificate information:
> ----------------------------------------------------------------------
> ---------------
> 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: eb.lan.at
> DNS server found: 10.3.42.1
> DNS server found: 10.3.42.2
> Nagle's algorithm (TCP_NODELAY) disabled.
> CONNECT secure.armstrongconsulting.com:443 HTTP/1.1
> Host: secure.armstrongconsulting.com HTTP/1.1
> User-Agent: http-api/1.32
> Proxy-Connection: keep-alive
>
>
> recvresp(): entered
> recvresp(): end with err
> http_close(): entered
>
>
> Thanks for your support.
>
> Mit freundlichen Grüßen/Best regards Mag. Alexander Grünwald
> ----------------------------------------------------------------------
> - 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
-----------------------------------------------------------------------

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
References:
- proxy access problem
  - From: Alexander Grünwald
- AW: proxy access problem
  - From: Alexander Grünwald
- Re: AW: proxy access problem
  - From: Scott Klement
- AW: AW: proxy access problem
  - From: Alexander Grünwald
Prev by Date: AW: AW: proxy access problem
Next by Date: Re: AW: AW: proxy access problem
Previous by thread: AW: AW: proxy access problem
Next by thread: Re: AW: AW: proxy access problem
Index(es):
- Date
- Thread