[ 
https://issues.apache.org/jira/browse/NIFI-14433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18043207#comment-18043207
 ] 

Rahul Verma commented on NIFI-14433:
------------------------------------

I investigated this issue and found that it originated from the 
{{stripProtocol}} method in 
{{{}nifi-frontend/src/main/frontend/libs/shared/src/services/nifi-common.service.ts{}}}.
 I applied a modification and verified the fix in NiFi 2.4, where it worked as 
expected.

In the latest 2.7 code, I observed that the handling for this logic has been 
updated, so the issue should be addressed in the upcoming release. Once the new 
version is available, I will upgrade and reconfirm the behavior.



Reference: NIFI-15276

> NiFi UI Generates Incorrect Port (:80) for PUT Requests Behind 
> SSL-Terminating Reverse Proxy (Cloud Run)
> --------------------------------------------------------------------------------------------------------
>
>                 Key: NIFI-14433
>                 URL: https://issues.apache.org/jira/browse/NIFI-14433
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core UI
>    Affects Versions: 2.3.0
>            Reporter: SivaAnanth Muthuveeranan
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> * *NiFi Version:* 2.3.0 (Tested using official {{apache/nifi:2.3.0}} image 
> and custom builds based on {{{}eclipse-temurin:latest{}}})
>  * *Deployment:* Docker container running on Google Cloud Run
>  * *Cloud Run Configuration:*
>  ** Internal Ingress (Load Balancer handles external HTTPS on port 443 and 
> forwards HTTP traffic to container port 8080)
>  ** VPC Connector configured
>  * *Proxy Headers (Sent by Cloud Run Proxy):*
>  ** {{X-Forwarded-Proto: https}}
>  ** {{X-Forwarded-Host: <your-cloud-run-hostname>}} (e.g., 
> {{{}nifi-internal-service-xxxxxxxxxx-uc.a.run.app{}}})
>  ** {{X-Forwarded-Port: 443}}
>  ** {{X-Forwarded-For: <client-ip>}}
>  * *NiFi {{nifi.properties}} Configuration (Key Settings):*
>  ** {{nifi.web.http.port=8080}}
>  ** {{nifi.web.http.host=}} (blank, listens on all interfaces)
>  ** {{nifi.web.https.port=}} (blank, HTTPS disabled on NiFi itself)
>  ** {{nifi.web.https.host=}} (blank)
>  ** {{nifi.web.proxy.context.path=/nifi}}
>  ** *Variations Tested for {{{}nifi.web.proxy.host{}}}:*
>  *** {{nifi.web.proxy.host=<your-cloud-run-hostname>:443}}
>  *** {{nifi.web.proxy.host=<your-cloud-run-hostname>}} (Plan A - no port)
>  *** {{nifi.web.proxy.host=}} (Blank/Unset) (Plan B)
>  ** *Variations Tested for {{{}nifi.web.proxy.scheme{}}}:*
>  *** Unset (Relying on {{{}X-Forwarded-Proto{}}})
>  *** {{nifi.web.proxy.scheme=https}} (Plan C - combined with Plan B host 
> setting)
>  ** {{nifi.security.user.login.identity.provider=}} (blank, for testing)
> *Description:*
> When running NiFi 2.3.0 behind an SSL-terminating reverse proxy like Google 
> Cloud Run (configured for internal ingress), the NiFi UI fails to correctly 
> construct the URL for certain API requests, specifically {{PUT}} requests 
> made when modifying components (e.g., saving processor configuration changes).
> While initial UI loading ({{{}GET{}}} requests) and component creation 
> ({{{}POST{}}} requests) correctly use the external HTTPS URL 
> ({{{}https://<hostname>/nifi-api/...{}}}), subsequent {{PUT}} requests 
> generated by the UI incorrectly target port 80 
> ({{{}https://<hostname>:80/nifi-api/...{}}}). This results in a browser error 
> ({{{}net::ERR_SSL_PROTOCOL_ERROR{}}}) because the Cloud Run proxy expects 
> HTTPS traffic on port 443, not HTTP traffic on port 80.
> This issue occurs despite various configurations of {{nifi.web.proxy.host}} 
> (including setting it with port 443, without the port, or leaving it unset) 
> and explicitly setting {{{}nifi.web.proxy.scheme=https{}}}. The backend 
> configuration appears correct based on container startup logs, but the 
> frontend JavaScript seems to ignore or misinterpret the proxy port 
> information for these specific {{PUT}} calls.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to