When producing a PDF, a new runtime instance of the form is created, to which the current form data is posted. Other aspects such as headers or request parameters are not taken into account.
A solution could be to forward headers and request parameters stored in the current containing document (#1736 covers parameters).
But ideally we would not have to create a new instance of the form. We would just ask the XForms engine to produce HTML output based on the current state.
Note that it can be problematic for the PDF output to depend on such parameters. For example, if you produce a PDF from the summary page of Form Runner, you also would have to make sure that the right URL parameters and headers are passed. The same goes when the PDF is sent to a service URL.
When producing a PDF, a new runtime instance of the form is created, to which the current form data is posted. Other aspects such as headers or request parameters are not taken into account.
A solution could be to forward headers and request parameters stored in the current containing document (#1736 covers parameters).
But ideally we would not have to create a new instance of the form. We would just ask the XForms engine to produce HTML output based on the current state.
Note that it can be problematic for the PDF output to depend on such parameters. For example, if you produce a PDF from the summary page of Form Runner, you also would have to make sure that the right URL parameters and headers are passed. The same goes when the PDF is sent to a service URL.
See also customer thread.