I was trying to use the Perl module "LWP::Simple" in a Perl CGI script, and it worked fine for "admins" on the Server (with Windows Authentication, the IIS/CGI environment knows the users Windows username and some of us (like me) are admins on the server). However, for all the rest of our non-admin users, they were getting "The specified CGI application misbehaved by not returning a complete set of HTTP headers". I narrowed it down to the "use LWP::Simple" line; if the line was in, the non-admins got the error; if the line was out, no error for anyone.

Since this was a "use" line, it seemed to me impossible to debug the error under IIS (no decent error logs!), so I broke down the LWP::Simple module (which just uses a lot of LWP::UserAgent stuff) and created the following simple script to reproduce the underlying error:

Since the error is not happening in a "use" line, we don't get the dreaded missing-http-headers error, and the real error appears on the screen:

Access is denied

This allowed me to narrow down to ONE line:

$ua->env_proxy;

If that line is in the code, the words "Access is denied" is shown on the screen for non-admins (admins do not get any errors). In both cases, the rest of the script works fine, but this error is preventing LWP::Simple from working at all (the error occurs in a "use" line and gives the missing-http-headers error).

While my workaround is to NOT use LWP::Simple and instead use LWP::UserAgent (skipping the "$ua->env_proxy" part), I would really like to know WHY "$ua->env_proxy" gives "Access is denied" for non-admins.

Do you get the same error from perl -MEncode -MEncode::Locale -e'print(decode("locale", "abc"))'?
–
ikegamiNov 4 '13 at 16:41

No, I get the output "abc". But, I can't get the problem to occur with CLI Perl, just CGI Perl. I've run the same CGI script under CLI (DOS prompt), and the error does NOT occur. I'd need an account that is NOT an admin on the local PC (for the CLI test) and NOT an admin on the server (for the CGI test), and I don't have one that's not at least a local admin.
–
jimtutNov 4 '13 at 17:43

1

Then what about use Encode; use Encode::Locale; print "Content-Type: text/plain\n\n"; print(decode("locale", "abc"));
–
ikegamiNov 4 '13 at 17:55

@ikegami: Running that in a CGI gives a nice clean "abc" output for admins, but gives the "specified CGI application misbehaved by not returning a complete set of HTTP headers" error for non-admins. What made you jump from LWP's env_proxy to Encode::Local? Is there a known issue with non-admins?
–
jimtutNov 5 '13 at 1:25

That's the only piece of env_proxy that does anything that isn't simple Perl code. You'll just have to keep tracing in that vein until you find the problem or a workaround.
–
ikegamiNov 5 '13 at 1:46

1 Answer
1

The underlying problem is a system call to chcp, which is an admin-only Windows command. There is no "clean" solution. Either comment out the line to that call, or put another chcp in your path that will be found before the built-in/admin-only version.

Thanks to @ikegami for the insightful comments that at least helped me figure out the "why", even if there wasn't a clean fix.

I filed a bug for this on GitHub (github.com/gisle/encode-locale/issues/6), and it's just been resolved. Not sure when the code will see an official release, but you can update Encode::Locale from the source file there, if this is affecting you.
–
jimtutJan 5 at 14:50