Skip to Main Content
AVEVA™ PI System™ Feedback Portal

Welcome to our feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Status No status
Product PI Integrators
Created by Guy Acciai
Created on Aug 16, 2022

Allow/Support URL Redirection within PI Integrator internal Webserver

Currently, PI integrator is setup on a SSL endpoint (443) and responds to https://FQDN, and https:/hostname, it ignores any requests to http:/FQDN (on port 80) This request is to allow some URL redirect or URL rewrite mechanism to allow URL forwarding for http://host or even https:/host -> https:/FQDN For certs issued with only a DNS of SAN=FQDN (no SAN=Host), having such forwarding would prevent a SSL cert warning about the URL and cert name mismatch. Finally, and more generally, given the possibility of future URL updates (like /PICoresight to /PIVision), or even host name moves, the ability to do 301 redirects is a pretty fundamental need for any webserver - (IIS,Apache,Nginx) apparently, the internal Webserver that Pi4BA uses (it's not IIS) is not configured to support redirects, nor is their any config file, or underlying setting exposed to support such functionality
  • Attach files
  • Kenneth Barber
    Reply
    |
    Aug 16, 2022
    I agree with this suggestion, but not the part about redirecting HTTP to HTTPS. The HTTP connection from the client can be intercepted as part of a man-in-the-middle attack before the redirect on the server occurs. That's why HSTS and HSTS preloading are a thing (i.e. instruct the client to use only HTTPS in the future).