getHTTPRequestData() empty

Hi, I can’t seem to get any values returned from getHTTPRequestData(). The
content is always empty.

Consider the following code:

#requestData.content#

The above is empty

Doing a cfdump also comes up empty on content

I read some bug in CF concerning this but I didn’t think it would be
applicable to Lucee.

I read somewhere changing from ajp to mod_proxy_http in my apache config.
So, I went ahead and did that with the same results.

Has anyone ran into this problem? If so, how did you resolve it?

Thanks

Are we talking about POST requests? If not, that’s completely normal. GET
requests do not have a body.

If we are talking about POST requests, what are you sending? What mime
type?

-GOn Tue, Aug 2, 2016 at 10:02 AM, <@computerservices> wrote:

Hi, I can’t seem to get any values returned from getHTTPRequestData(). The
content is always empty.

Consider the following code:

#requestData.content#

The above is empty

Doing a cfdump also comes up empty on content

I read some bug in CF concerning this but I didn’t think it would be
applicable to Lucee.

I read somewhere changing from ajp to mod_proxy_http in my apache config.
So, I went ahead and did that with the same results.

Has anyone ran into this problem? If so, how did you resolve it?

Thanks


Get 10% off of the regular price for this years CFCamp in Munich, Germany
(Oct. 20th & 21st) with the Lucee discount code Lucee@cfcamp. 189€
instead of 210€. Visit
CFCamp 2016

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/f1df4647-461f-475e-b53b-c13078bc60f3%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f1df4647-461f-475e-b53b-c13078bc60f3%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

This is legitimately an issue. It is very difficult to reproduce, but about
5%-ish of requests posted into one of my apps ends up having nothing in the
getHTTPRequestData.content. This post provided a decent work
around: http://stackoverflow.com/questions/23758116/coldfusion-ajax-json-empty-request-body/24819650#24819650?newreg=2bd57b8db5304938a5e221c13f165483.

This is the stack I am running
CFML engine: Lucee 5.1.0.34
OS: linux
Servlet: Tomcat + nginx
Framework: Coldbox 4.3

The Content-Type of the post is “application/json”

This is a pretty staggering bug imo. Has anyone else seen some of this
behavior?On Tuesday, August 2, 2016 at 1:54:47 PM UTC-5, computer...@gmail.com wrote:

there is something wrong. I used postman for Chrome and specified a POST
method and still GetHTTPRequestData is empty. I verified that both CGI
Request Method and HTTP Request Data Methods were POST:

CGI Request method: POST
HTTP Request Data method: POST

The funny thing is that this works perfectly on another website with the
exact same code. I wonder if Mura CMS is somehow messing with this. This is
a custom app within MURA CMS. I will try posting something there too. Any
ideas? Do I need to adjust something in application.cfc? I think I read
something about that somewhere.

On Tuesday, August 2, 2016 at 1:57:41 PM UTC-4, Joseph Gooch wrote:

It worked… when?

GetHTTPRequestData has never returned anything in content for a GET
request. It can’t. GET requests by HTTP definition do not have a content
body.

If you want the parameters passed from a GET request - see
CGI.QUERY_STRING

If you’re going from samples here:
https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.cfm

Notice how all the variables are pulled from FORM scope. (assuming a
POST request)

You either need to modify your code to use a method to pull the
appropriate data from the appropriate place, or determine why paypal is now
using GET instead of POST.
-G

On Tue, Aug 2, 2016 at 1:53 PM, computer...@gmail.com wrote:

CGI Request method: GET
HTTP Request Data method: GET

They are both GET. I can’t control what method Paypal uses as far as I
know. Like it said before, this method worked.

On Tuesday, August 2, 2016 at 1:37:37 PM UTC-4, Joseph Gooch wrote:

What’s in CGI.REQUEST_METHOD and getHTTPRequestData().method?

On Tue, Aug 2, 2016 at 1:15 PM, computer...@gmail.com wrote:

I’m trying to get paypal integration to work. In the past the method
below worked if I remember correctly:

Paypal would make a request to an ipn.cfm page on the server as
follows:

https://www.domain.tld/ipn/ipn.cfm?transaction_subject=Product
https://www.domain.tld/ipn/ipn.cfm?transaction_subject=Product
Name&payment_date=15:32:25 Aug 01, 2016
PDT&txn_type=subscr_payment&subscr_id=I-123456789&last_name=Smith&residence_country=US&item_name=Product
name&payment_gross=10.00&mc_currency=USD&business=someone@somedomain.tld&payment_type=instant&protection_eligibility=Ineligible&verify_sign=123456789&payer_status=unverified&payer_email=someone@somedomain.tld&txn_id=123456789&receiver_email=someone@somedomain.tld&first_name=John&payer_id=123456789&receiver_id=1234567898&payment_status=Completed&payment_fee=10.00&mc_fee=10.00&mc_gross=10.00&custom=123456789&charset=windows-1252&notify_version=3.8&ipn_track_id=123456789

The ipn.cfm page has the following code to catch the submitted request:

The it would get the requestdata.content and post back to paypal to
verify its integrity as follows:

*<CFHTTP
url=“https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate&#requestData.content#
https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate&#requestData.content%23

*

If it got back the desired result:

<CFIF #CFHTTP.FileContent# is “VERIFIED”>

It would create local variables:

<CFIF IsDefined(“FORM.item_name”)>


<!— check that payment_status=Completed —>
<CFIF IsDefined(“FORM.payment_status”)>


None of that works cause getHTTPRequestData() is empty

Hopefully I explained it clearly and it answers your question.

On Tuesday, August 2, 2016 at 12:01:36 PM UTC-4, Joseph Gooch wrote:

Are we talking about POST requests? If not, that’s completely
normal. GET requests do not have a body.

If we are talking about POST requests, what are you sending? What
mime type?

-G

On Tue, Aug 2, 2016 at 10:02 AM, computer...@gmail.com wrote:

Hi, I can’t seem to get any values returned from
getHTTPRequestData(). The content is always empty.

Consider the following code:

#requestData.content#

The above is empty

Doing a cfdump also comes up empty on content

I read some bug in CF concerning this but I didn’t think it would be
applicable to Lucee.

I read somewhere changing from ajp to mod_proxy_http in my apache
config. So, I went ahead and did that with the same results.

Has anyone ran into this problem? If so, how did you resolve it?

Thanks


Get 10% off of the regular price for this years CFCamp in Munich,
Germany (Oct. 20th & 21st) with the Lucee discount code Lucee@cfcamp. 189€
instead of 210€. Visit
CFCamp 2016

You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/f1df4647-461f-475e-b53b-c13078bc60f3%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f1df4647-461f-475e-b53b-c13078bc60f3%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Get 10% off of the regular price for this years CFCamp in Munich,
Germany (Oct. 20th & 21st) with the Lucee discount code Lucee@cfcamp. 189€
instead of 210€. Visit
CFCamp 2016


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/028a6675-1295-4084-b3ac-f8d3ec6585eb%40googlegroups.com
https://groups.google.com/d/msgid/lucee/028a6675-1295-4084-b3ac-f8d3ec6585eb%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Get 10% off of the regular price for this years CFCamp in Munich,
Germany (Oct. 20th & 21st) with the Lucee discount code Lucee@cfcamp. 189€
instead of 210€. Visit
CFCamp 2016


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/26c89a10-1450-4dc7-ac0c-e4682afdaf41%40googlegroups.com
https://groups.google.com/d/msgid/lucee/26c89a10-1450-4dc7-ac0c-e4682afdaf41%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

does it happen with all browsers?On Wed, Dec 14, 2016 at 6:55 AM, <@ben> wrote:

This is legitimately an issue. It is very difficult to reproduce, but
about 5%-ish of requests posted into one of my apps ends up having nothing
in the getHTTPRequestData.content. This post provided a decent work around:
coldfusion ajax json - empty request body - Stack Overflow
request-body/24819650#24819650?newreg=2bd57b8db5304938a5e221c13f165483.

This is the stack I am running
CFML engine: Lucee 5.1.0.34
OS: linux
Servlet: Tomcat + nginx
Framework: Coldbox 4.3

The Content-Type of the post is “application/json”

This is a pretty staggering bug imo. Has anyone else seen some of this
behavior?

On Tuesday, August 2, 2016 at 1:54:47 PM UTC-5, computer...@gmail.com wrote:

there is something wrong. I used postman for Chrome and specified a POST
method and still GetHTTPRequestData is empty. I verified that both CGI
Request Method and HTTP Request Data Methods were POST:

CGI Request method: POST
HTTP Request Data method: POST

The funny thing is that this works perfectly on another website with the
exact same code. I wonder if Mura CMS is somehow messing with this. This is
a custom app within MURA CMS. I will try posting something there too. Any
ideas? Do I need to adjust something in application.cfc? I think I read
something about that somewhere.

On Tuesday, August 2, 2016 at 1:57:41 PM UTC-4, Joseph Gooch wrote:

It worked… when?

GetHTTPRequestData has never returned anything in content for a GET
request. It can’t. GET requests by HTTP definition do not have a content
body.

If you want the parameters passed from a GET request - see
CGI.QUERY_STRING

If you’re going from samples here:
https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.cfm

Notice how all the variables are pulled from FORM scope. (assuming a
POST request)

You either need to modify your code to use a method to pull the
appropriate data from the appropriate place, or determine why paypal is now
using GET instead of POST.
-G

On Tue, Aug 2, 2016 at 1:53 PM, computer...@gmail.com wrote:

CGI Request method: GET
HTTP Request Data method: GET

They are both GET. I can’t control what method Paypal uses as far as I
know. Like it said before, this method worked.

On Tuesday, August 2, 2016 at 1:37:37 PM UTC-4, Joseph Gooch wrote:

What’s in CGI.REQUEST_METHOD and getHTTPRequestData().method?

On Tue, Aug 2, 2016 at 1:15 PM, computer...@gmail.com wrote:

I’m trying to get paypal integration to work. In the past the method
below worked if I remember correctly:

Paypal would make a request to an ipn.cfm page on the server as
follows:

https://www.domain.tld/ipn/ipn.cfm?transaction_subject=Product
https://www.domain.tld/ipn/ipn.cfm?transaction_subject=Product
Name&payment_date=15:32:25 Aug 01, 2016
PDT&txn_type=subscr_payment&subscr_id=I-123456789&last_name=Smith&residence_country=US&item_name=Product
name&payment_gross=10.00&mc_currency=USD&business=someone@somedomain.tld&payment_type=instant&protection_eligibility=Ineligible&verify_sign=123456789&payer_status=unverified&payer_email=someone@somedomain.tld&txn_id=123456789&receiver_email=someone@somedomain.tld&first_name=John&payer_id=123456789&receiver_id=1234567898&payment_status=Completed&payment_fee=10.00&mc_fee=10.00&mc_gross=10.00&custom=123456789&charset=windows-1252&notify_version=3.8&ipn_track_id=123456789

The ipn.cfm page has the following code to catch the submitted
request:

The it would get the requestdata.content and post back to paypal to
verify its integrity as follows:

*<CFHTTP
url=“https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate&#requestData.content#
https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate&#requestData.content%23

*

If it got back the desired result:

<CFIF #CFHTTP.FileContent# is “VERIFIED”>

It would create local variables:

<CFIF IsDefined(“FORM.item_name”)>


<!— check that payment_status=Completed —>
<CFIF IsDefined(“FORM.payment_status”)>


None of that works cause getHTTPRequestData() is empty

Hopefully I explained it clearly and it answers your question.

On Tuesday, August 2, 2016 at 12:01:36 PM UTC-4, Joseph Gooch wrote:

Are we talking about POST requests? If not, that’s completely
normal. GET requests do not have a body.

If we are talking about POST requests, what are you sending? What
mime type?

-G

On Tue, Aug 2, 2016 at 10:02 AM, computer...@gmail.com wrote:

Hi, I can’t seem to get any values returned from
getHTTPRequestData(). The content is always empty.

Consider the following code:

#requestData.content#

The above is empty

Doing a cfdump also comes up empty on content

I read some bug in CF concerning this but I didn’t think it would
be applicable to Lucee.

I read somewhere changing from ajp to mod_proxy_http in my apache
config. So, I went ahead and did that with the same results.

Has anyone ran into this problem? If so, how did you resolve it?

Thanks


Get 10% off of the regular price for this years CFCamp in Munich,
Germany (Oct. 20th & 21st) with the Lucee discount code Lucee@cfcamp.
189€ instead of 210€. Visit https://ti.to/cfcamp/cfcamp-20
16/discount/Lucee@cfcamp

You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/f1df4647-461f-475e-
b53b-c13078bc60f3%40googlegroups.com
https://groups.google.com/d/msgid/lucee/f1df4647-461f-475e-b53b-c13078bc60f3%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Get 10% off of the regular price for this years CFCamp in Munich,
Germany (Oct. 20th & 21st) with the Lucee discount code Lucee@cfcamp.
189€ instead of 210€. Visit https://ti.to/cfcamp/cfcamp-20
16/discount/Lucee@cfcamp


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it,
send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/028a6675-1295-4084-
b3ac-f8d3ec6585eb%40googlegroups.com
https://groups.google.com/d/msgid/lucee/028a6675-1295-4084-b3ac-f8d3ec6585eb%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Get 10% off of the regular price for this years CFCamp in Munich,
Germany (Oct. 20th & 21st) with the Lucee discount code Lucee@cfcamp.
189€ instead of 210€. Visit https://ti.to/cfcamp/cfcamp-20
16/discount/Lucee@cfcamp


You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/lucee/26c89a10-1450-4dc7-ac0c-e4682afdaf41%40googlegroups.com
https://groups.google.com/d/msgid/lucee/26c89a10-1450-4dc7-ac0c-e4682afdaf41%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/86928d68-5953-43e6-9289-0fe30f4cd37a%40googlegroups.com
https://groups.google.com/d/msgid/lucee/86928d68-5953-43e6-9289-0fe30f4cd37a%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Zac Spitzer
+61 405 847 168

Ben, I am using the exact same stack as you and I am seeing the same behavior as well. I have a 3rd party system sending push notifications to my app using POST and application/json.

If I call getHTTPRequestData().content in my handler it’s always empty. If I call it earlier in my request lifecycle it contains the JSON body.

So for now as a workaround I set up a preProcess interceptor in my app and in there I add getHTTPRequestData().content to the private request collection:

prc.requestbody = getHTTPRequestData().content;

I suspect somewhere in the ColdBox lifecycle the content is being reset, but i have not had the time to try to pinpoint where/when. The workaround is adequate for me at the moment.

  • Sean> On Dec 13, 2016, at 2:55 PM, @ben wrote:

This is legitimately an issue. It is very difficult to reproduce, but about 5%-ish of requests posted into one of my apps ends up having nothing in the getHTTPRequestData.content. This post provided a decent work around: http://stackoverflow.com/questions/23758116/coldfusion-ajax-json-empty-request-body/24819650#24819650?newreg=2bd57b8db5304938a5e221c13f165483.

This is the stack I am running
CFML engine: Lucee 5.1.0.34
OS: linux
Servlet: Tomcat + nginx
Framework: Coldbox 4.3

The Content-Type of the post is “application/json”

This is a pretty staggering bug imo. Has anyone else seen some of this behavior?

I can’t seem to find a ticket for this on Jira. Probably a good idea
to raise one.On 15 December 2016 at 00:42, Dominic Watson <@Dominic_Watson> wrote:

We encountered this same bug with Preside. We found that we could always get the HTTP body at the start of the request in Application.cfc$onRequestStart(), but that later on in the request it was lost.

Just as a side note: we use FW/1 and haven’t experienced any problems
with GetHttpRequestData().On 15 December 2016 at 00:42, Dominic Watson <@Dominic_Watson> wrote:

We encountered this same bug with Preside.

On 14 December 2016 at 16:47, Sean Daniels <@Sean_Daniels> wrote:

I suspect somewhere in the ColdBox lifecycle the content is being reset, but i have not had the time to try to pinpoint where/when.

I had thought it was raised but apparently not. There is more than one
thread in the Railo list. Here is the one in which this solution was put
forward:

https://groups.google.com/forum/#!msg/railo/EjspSjpALqg/j7CxnA2CfG4J;context-place=searchin/railo/request$20body$20|sort:relevance

I’ve raised a JIRA: [LDEV-1119] - Lucee 15 December 2016 at 08:51, Julian Halliwell <@Julian_Halliwell> wrote:

I can’t seem to find a ticket for this on Jira. Probably a good idea
to raise one.

On 15 December 2016 at 00:42, Dominic Watson <@Dominic_Watson> wrote:

We encountered this same bug with Preside. We found that we could always
get the HTTP body at the start of the request in Application.cfc$onRequestStart(),
but that later on in the request it was lost.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/CAC_5Voqsp3WvwnKY0z1Q3Jnp18wWO2H%3DwWO5h13dme9AbLKXFg%40mail.
gmail.com.
For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8
CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended
solely for the addressee, is strictly confidential and may also be subject
to legal, professional or other privilege or may be protected by work
product immunity or other legal rules. If you are not the addressee please
do not read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

We encountered this same bug with Preside. We found that we could always
get the HTTP body at the start of the request in
Application.cfc$onRequestStart(), but that later on in the request it was
lost. We worked around it with:

public boolean function onRequestStart( required string targetPage ) {

_readHttpBodyNowBecauseLuceeSeemsToBeSporadicallyBlankingItFurtherDownTheRequest();

}

private void function
_readHttpBodyNowBecauseLuceeSeemsToBeSporadicallyBlankingItFurtherDownTheRequest()
{
request.http = { body = ToString( GetHttpRequestData().content ) };
}

Then later we can refer to request.http.body.

HTH

DominicOn 14 December 2016 at 16:47, Sean Daniels <@Sean_Daniels> wrote:

Ben, I am using the exact same stack as you and I am seeing the same
behavior as well. I have a 3rd party system sending push notifications to
my app using POST and application/json.

If I call getHTTPRequestData().content in my handler it’s always empty. If
I call it earlier in my request lifecycle it contains the JSON body.

So for now as a workaround I set up a preProcess interceptor in my app and
in there I add getHTTPRequestData().content to the private request
collection:

prc.requestbody = getHTTPRequestData().content;

I suspect somewhere in the ColdBox lifecycle the content is being reset,
but i have not had the time to try to pinpoint where/when. The workaround
is adequate for me at the moment.

  • Sean

On Dec 13, 2016, at 2:55 PM, @ben wrote:

This is legitimately an issue. It is very difficult to reproduce, but
about 5%-ish of requests posted into one of my apps ends up having nothing
in the getHTTPRequestData.content. This post provided a decent work around:
http://stackoverflow.com/questions/23758116/coldfusion-
ajax-json-empty-request-body/24819650#24819650?newreg=
2bd57b8db5304938a5e221c13f165483.

This is the stack I am running
CFML engine: Lucee 5.1.0.34
OS: linux
Servlet: Tomcat + nginx
Framework: Coldbox 4.3

The Content-Type of the post is “application/json”

This is a pretty staggering bug imo. Has anyone else seen some of this
behavior?


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/lucee/A9E1B760-E66D-4FF5-916E-2FC5BE2A6C38%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8
CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended
solely for the addressee, is strictly confidential and may also be subject
to legal, professional or other privilege or may be protected by work
product immunity or other legal rules. If you are not the addressee please
do not read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB