tracker issue : CF-3154884

select a category, or use search below
(searches all categories and all time range)
Title:

CGI.HTTP_USER_AGENT is [empty string] for task handler events

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/NotABug

Reporter/Name(from Bugbase): Aaron Neff / Aaron Neff (Aaron Neff)

Created: 04/01/2012

Components: Scheduler

Versions: 10.0

Failure Type:

Found In Build/Fixed In Build: Public Beta /

Priority/Frequency: Normal / Some users will encounter

Locale/System: English / Win All

Vote Count: 0

CGI.HTTP_USER_AGENT is CFSCHEDULE for task requests. (good)

CGI.HTTP_USER_AGENT is [empty string] for task handler event requests. (bad)

It should be CFSCHEDULE in both cases.  Task handler event requests generate sessions.  Thus, task handler event requests should be identifiable (via CGI.HTTP_USER_AGENT), so that THIS.sessionTimeout can be set appropriately for these requests.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3154884

External Customer Info:
External Company:  
External Customer Name: itisdesign
External Customer Email:

Attachments:

  1. November 17, 2014 00:00:00: 1_3154884.zip
  2. November 17, 2014 00:00:00: 2_3154884_2.zip
  3. November 17, 2014 00:00:00: 3_3154884_3.zip
  4. December 05, 2014 00:00:00: 4_bug.zip
  5. December 07, 2014 00:00:00: 5_3154884_getHTTPRequestData.zip

Comments:

Related thread: http://prerelease.adobe.com/r/?e6268d31d5894431bb32183221b0e38f
Comment by External U.
19812 | April 01, 2012 12:24:44 PM GMT
Task event calls are not unidentifiable and create sessions. That's not a good combination.
Comment by External U.
19813 | April 03, 2012 11:47:18 AM GMT
I mean: Task event calls are not identifiable and create sessions. That's not a good combination.
Comment by External U.
19814 | April 03, 2012 11:48:44 AM GMT
Update: I'd like to change my original request. My original request: CGI.HTTP_USER_AGENT should be CFSCHEDULE for task handler event requests. My new request: CGI.HTTP_USER_AGENT should be CFSCHEDULEEVENT for task handler event requests. Currently, CGI.HTTP_USER_AGENT is still [empty string] for task handler event requests. To repro, just do SERVER.foo=duplicate(CGI) within a task handler method and then cfdump SERVER.foo via another .cfm and see the value for CGI.HTTP_USER_AGENT was [empty string]. Sometime, it would be nice if CGI.HTTP_USER_AGENT could be populated as CFSCHEDULEEVENT so we can handle those requests w/in Application.cfc's pseudo constructor if necessary. Thanks!, -Aaron
Comment by External U.
19815 | November 17, 2014 01:45:00 AM GMT
Repro: 1) Unzip attached CF-3154884.zip 2) In createtask.cfm, change path in eventHandler="TaskHandler" if necessary (per-app mappings seem to be ignored in this attribute) 3) Run createtask.cfm 4) Run index.cfm 5) See CGI.HTTP_USER_AGENT is [empty string] Can it please be CFSCHEDULEEVENT, so we can identify these requests in Application.cfc's pseudo constructor? Thanks!, -Aaron
Comment by External U.
19816 | November 17, 2014 02:22:41 AM GMT
Please disregard "CF-3154884.zip" and "CF-3154884_2.zip" and repro in last comment. Updated repro: 1) Unzip CF-3154884_3.zip 2) Run createtask.cfm 3) Run index.cfm 4) See CGI.HTTP_USER_AGENT is [empty string] Thanks!, -Aaron
Comment by External U.
19817 | November 17, 2014 03:58:26 AM GMT
All the events invoked in the eventhandler are method invocation done by internal code and not normal HTTP requests. They are basically event triggers. Hence CGI scope does not make sense there. When tasks are executed they follow the normal HTTP request flow and hence CGI variables are available
Comment by Uday O.
19818 | November 20, 2014 04:43:03 AM GMT
Hi Uday, The issue is that the method invocation done by internal code is still reaching Application.cfc's pseudo constructor. Thus, if THIS.sessionManagement=true, then these invocations are still creating sessions. These sessions are useless and waste system resources. I want to set THIS.sessionManagement=false if CGI.HTTP_USER_AGENT is CFSCHEDULEEVENT (meaning, disable session management if internal code invocation). A CF engineer (omitting name) had a good idea once: "A better thing to do, IMO, is to have a method which tells whether the call is happening in the context of an HTTP request or not." Thanks!, -Aaron
Comment by External U.
19819 | November 21, 2014 08:37:39 AM GMT
Hi Uday, Please disregard my last comment. I can use CF11's Elvis operator to determine if request is HTTP: function isHTTPRequest() { return (structCount(getHTTPRequestData())?:false)?true:false; } Using Elvis operator b/c isNull(getHTTPRequestData()) throws exception for non-HTTP requests. This ticket can be closed. It would be nice if CF12 added the above isHTTPRequest() function. Thanks!, -Aaron
Comment by External U.
19820 | November 23, 2014 02:30:35 AM GMT
To clarify: getHTTPRequestData() throws java.lang.NullPointerException for non-HTTP requests. It should probably just return an empty struct.
Comment by External U.
19821 | November 23, 2014 02:42:43 AM GMT
getHTTPRequestData() returns an empty struct for non-HTTP Requests for me. I will attach the code I used. Could you send some repro code? Will be logging an ER for isHTTPRequest().
Comment by Suchika S.
19822 | December 05, 2014 06:52:36 AM GMT
Hi Suchika, I've attached repro CF-3154884_getHTTPRequestData.zip. Please refer to comments in the code. To see related issue #CF-3151858, please enable J2EE sessions. Regarding isHTTPRequest(), I've updated #CF-3844994 (RequestGetMetadata()) to include RequestGetMetadata().isHTTPRequest. #CF-3844994 is still marked Open/Unverified. Thanks!, -Aaron P.S. Sorry, my <cfschedule> in previous repro had invalid startdate & starttime so the task wasn't always running. I've fixed this in the new attached repro.
Comment by External U.
19823 | December 07, 2014 12:08:26 AM GMT
Hi Aaron, ER for isHttpRequest is already logged by you.(#CF-3844994) . For getHTTPRequestData returning NPE ,I will log a bug. I have reopened the bug #CF-3151858. I am closing this bug and will track the other related bugs. Thanks, Suchika. P.S. Thanks for looking into the bugs so closely and also for quick responses! :)
Comment by Suchika S.
19824 | December 08, 2014 12:42:40 AM GMT
Hi Suchika, You're very welcome and thanks very much for the follow-up and for re-opening #CF-3151858 and for filing #CF-3863594! Thanks!, -Aaron
Comment by External U.
19825 | December 08, 2014 02:39:01 AM GMT
Adobe, You need to provide a method to identify if requests are HTTP or not. Adobe even told me this once in another discussion: ----------- "A better thing to do, IMO, is to have a method which tells whether the call is happening in the context of an HTTP request or not." ----------- Since CF CF-3863594 was closed, please ensure RequestGetMetadata().isHTTPRequest is added in CF12 (part of #CF-3844994). Thanks!, -Aaron
Comment by External U.
19826 | September 15, 2015 01:07:47 PM GMT