1287960 - http 400 response bodies not coming into adobe flash player

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect, P5)

Description

[chrsmrtn]

Attachment: missinghttp400response.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586

Steps to reproduce:

build an apache flex project can make a rest request and handles the reply through the ResultEvent.RESULT and FaultEvent.FAULT to handle the reply for the CallResponder class.


Actual results:

When I receive anything other than HTTP 200, I'm unable to access the message in the fault handler.


Expected results:

In the FAULT handler I am hoping to receive the response body so I can interpret, handle and even forward the reply to the user that is using the ApacheFlex application.

I compressed the .har file capturing the request that resulted in a HTTP 400 response, and I've attached a code snip where i'm expecting event.message.body to contain the JSON response body found in the .har file.

Other browser allows this and I believe Firefox also used to allow this as well, but it has been a while since I tested in Firefox.

Comment 1

[chrsmrtn]

Seems the first time i can get the response body, sometimes i do not get it on subsequent failed requests

Comment 2

[chrsmrtn]

Also finding now i am not even getting it on the "first time" anymore either. I can restart the browser, reload the app, and then try the request again.  Upon the failure of the request, i don't get the body content.

Hope this extra detail helps.

Comment 3

[Loic]

Do you have a minimal testcase fully working?

In addition, don't expect too much work from Mozilla because Flash is on the descending slope.

Comment 4

[chrsmrtn]

I've attached a minimal working ApacheFlex application (HTTP400Test.zip).  It's a site, but you can run it from your local machine.  The service endpoint we are calling is not publically available so i gave you two request captures (fiddler format and httparchive format) in case you have a way to "reply" these requests. I've also included an autoresponder ruleset that can be imported into Fiddler if that's a utility your team uses.

When you test you initially get the response body. You will see: "Server retruend the following error: An error occurred while sending the request => The remote name could not be resolved: 'site.online.tableau.com'" below the button.

But continue to make subsequent requests and after about 10 requests 'null' is started to be returned. Then you will see "Server returned the following error: null".  The 'null' portion of that reply represents the event.message.body content.

This same app run with Internet Explorer will continue to report the response body no matter now many times you make the request.

I understand and recognize that the industry is seeing a decline in Flash Player. The inconsistent behavior makes me concerned that there may be a bigger issue here with Firefox and Flash Player.  This behavior used to consistently work where we were able to certify our UI to run in Firefox.

Comment 5

[chrsmrtn]

Attachment: test environment for http400 response handling

attaching test app

Comment 6

[Benjamin Smedberg]

Do you know if this is a regression from something that used to work in a prior version? If so, could you use the tool at http://mozilla.github.io/mozregression/ to get a regression range?

The NPAPI plugin layer does support plugins asking to receive all HTTP responses (not just successful ones), and I believe Flash does use this setting, but this may be something that you need to contact Adobe support about first.

Comment 7

[chrsmrtn]

Unfortunately no. I believe it was well over a year ago when I qualified Firefox as a browser that could consistently give us the HTTP 400 responses in both debug and live versions of Flash Player.

I believe Flash Player does ask for the http responses as it works at first but then starts to fail. To help me in logging a ticket with Adobe, could you confirm that the NPAPI consistently receives the request for the http response body and consistently returns it even though the test starts to fail and the response does not surface up?

If I can have that confirmation, it would be very easy for Adobe to know it is an issue with their Flash Player and not the browser.

Sorry to put this "in your court", but when debugging an issue I always start from the source and work "outward" as it were.  So I've confirmed our API is indeed giving the browser the error message consistently, so now I seek to know if the browser is consistently giving the Flash Player the response.

Regards,

Chris

Comment 8

[Benjamin Smedberg]

I can point you at the code which does this checking, so you can check the right logs. Here's the code in question:

When a stream has a non-success code, we check here: http://searchfox.org/mozilla-central/rev/44f6964ba95b8ddd8ebf70c55b34cd2323afeef4/dom/plugins/base/nsPluginStreamListenerPeer.cpp#468
This should trigger the call and logging here: http://searchfox.org/mozilla-central/rev/44f6964ba95b8ddd8ebf70c55b34cd2323afeef4/dom/plugins/base/nsNPAPIPluginInstance.cpp#637

So you may not need to actually attach a debugger, but just turn on NSPR logging of plugin calls and check the traffic. Set the following in your environment:

NSPR_LOG_MODULES=PluginNPN:5,PluginNPP:5,Plugin:5
NSPR_LOG_FILE=/path/to/logfile.txt

See https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/Reference/NSPR_LOG_MODULES for more details about logging.

If you were going to check this in a debugger, you'd can use the Mozilla symbol server to debug our release builds (you don't have to build yourself): https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_symbol_server  You would have to attach to the main Firefox process, not the plugin-container process.

Comment 9

[u597032]

Adobe Flash is no longer supported.