in reply to Re: Help sought determining why Frontier::Client reporting too many header lines
in thread Help sought determining why Frontier::Client reporting too many header lines

I haven't been able to figure out how to print out the headers to see whether there are too many. There really isn't much before the method:
BEGIN { use Log::Log4perl qw(:easy); Log::Log4perl->easy_init( { file => ">> /tmp/uiv2_logfile.txt", level => $INFO, }, ); $SIG{__DIE__} = sub { if($^S) { # We're in an eval {} and don't want to log # this message but catch it later return; } $Log::Log4perl::caller_depth++; LOGDIE @_; }; } use strict; use warnings; use diagnostics; use CGI; use CGI::Carp 'fatalsToBrowser'; use Frontier::RPC2; use Frontier::Responder; use DBI; $ENV{ORACLE_HOME} = '/vol/ora_client/product/10.2.0.2'; my $Schema = "lv"; my $conn_data="/path/to/connection_information"; open (CONNECTION_DATA, $conn_data) or die "Failed to open connection data file\n"; my $DBHOST = <CONNECTION_DATA>; my $DBUSER = <CONNECTION_DATA>; my $DBPASS = <CONNECTION_DATA>; close (CONNECTION_DATA); chomp ($DBHOST); chomp ($DBUSER); chomp ($DBPASS); my $res = Frontier::Responder->new( methods => { Get_Login => \&Get_Login, Get_Last_Name => \&Get_Last_Name, Get_First_Name => \&Get_First_Name, Get_Dept_No => \&Get_Dept_No, Get_AltEmpNo => \&Get_AltEmpNo, Get_Supervisor_Emp_No => \&Get_Supervisor_Emp_No, Get_Job_Class => \&Get_Job_Class, GetAllByLastName => \&GetAllByLastName, GetAllByFirstName => \&GetAllByFirstName, GetAllByFirstOrLastName => \&GetAllByFirstOrLastName +, GetAllByLogin => \&GetAllByLogin, GetAllByDept => \&GetAllByDept, GetAllByEmpNo => \&GetAllByEmpNo, GetAllByDeptExtRoom => \&GetAllByDeptExtRoom, GetAllBySupervisor => \&GetAllBySupervisor, GetUnixContractorInfo => \&GetUnixContractorInfo, GetManagerList => \&GetManagerList, GetPeopleReportingTo => \&GetPeopleReportingTo, Get_LoginByEmpNo => \&Get_LoginByEmpNo } ); print $res->answer;
: followed by each of the methods. : Any setting of headers is being done inside Frontier. And, as I said, I've tests for each of the methods, and most are working fine. For that matter, if I pass this method a different department number, it works okay. I have 2 departments in my test data - one department has 2 people in it, and the other has 27 people in it. In the live system, there's going to be departments with a couple hundred people in it! I don't see anything obvious in the method that should impact the headers. But I don't know what code is generating the headers, so I can't tell if there's something weird in the CGI environment that's influcing the code in this one case.
  • Comment on Re^2: Help sought determining why Frontier::Client reporting too many header lines
  • Download Code

Replies are listed 'Best First'.
Re^3: Help sought determining why Frontier::Client reporting too many header lines
by sierpinski (Chaplain) on Jun 28, 2010 at 19:25 UTC
    To test to see if it is the cookies issue (I'm sure there can be multiple causes for this error -- but cookies is the first one I've found documented) you can clear cache on your browser, and turn on 'ask me every time' for cookies (and delete the existing cookies) and see how many times you get prompted for cookies. It's very possible that each user has multiple cookies (or generates multiple headers in general, if cookies aren't the culprit) that are causing the error. (or just browse your cookies afterward to see how many exist for your site after using the dept with 27 people)

    If it's directly related to the number of people in that department, then I'd have to deduce that it's doing something for each of those people. It might be cookies, it might be some other type of header, but that has to be part of the reason.

    Have you tried looking into the module code to see what it's trying to do? I don't have that module handy, but it might spill the beans as to what's going on, and perhaps there is some option to change the behavior to prevent this issue.

    I looked on CPAN and found this bug for one of the Frontier modules. It talks about a 500 error, perhaps it's related to the one you are receiving. It's very possible that it's a bug in the module and nothing in your code can prevent it, which in case you'll either have to get it fixed yourself, or hope the author fixes it. I'd definitely examine the source of the module though to see if you can spot where the issue really is. Unfortunately I can't do that at the moment, but I will try to take a look later on if I can.

    I hope that was helpful.
      Thank you for your suggestions. In this particular case, the web service isn't being invoked by a browser, but a small piece of perl code, so I don't think there's any cookies involved. The specific error being generated is coming deep within Net::HTML, which is trying to read header lines and is finding more than 128 headers. I have been trying to figure out how to see the headers and xml that is being generated, but so far, I have been unsuccessful in all my attempts. The code in Frontier::Response is pretty simple and I don't see anything there that is obvious. So the problem must be deep within the XML generation process and I've just not figured out how to see what is going on there.
        Don't forget though that the browser doesn't generate the cookie. The web server does. The browser (or you as the user) accepts it and stores it locally in the browsers computer. A piece of perl code could very easily generate cookies.

        Have you tried either of the previous methods I suggested to see if that is the issue? It might be a longshot, but it's an easy check, if only to rule it out as a possible cause.