[10.5] Apple's parental controls replace last 2 chars of input text with "Pr" on POST




Networking: HTTP
8 years ago
2 years ago


(Reporter: Miquel Botanch, Unassigned)


Mac OS X

Firefox Tracking Flags

(Not tracked)




(2 attachments)



8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; ca-es) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16
Build Identifier: Mozilla/5.0 (Macintosh. U. PPC Mac OS X 10.5. ca: rv:1.9.09) Gecko/2009040820 Firefox/3.09

We have a website in the intranet that works flawless on MacOsx 10.5.6 (intel)  firefox version 3.09 or any windows / firefox version.

The problem only occurs on MacOsx (tried 10.5.6 and 10.5.5)  (powerpc) . All firefox 3.0X versions.

I've a form submitted via POST. and several inputs on it.

for example:

<input type="text" name="test1" value="test1"> 
<input type="text" name="test2" value="test2">

when I receive the POST on php
print $_POST["test1"];
print $_POST["test2"];

test1 = "test1"  ok 
test2 = "tesPr"  <- incorrect

it always happens on the last input of the form.
What it does is to remove the last two chars of the last input, and replace it for "Pr"

I'm not using any extension / addon.

Reproducible: Always

Steps to Reproduce:
<input type="text" name="test1" value="test1"> 
<input type="text" name="test2" value="test2">
Actual Results:  
print $_POST["test1"];
print $_POST["test2"];

test1 = "test1"  ok 
test2 = "tesPr"  <- incorrect

Expected Results:  
print $_POST["test1"];
print $_POST["test2"];

test1 = "test1"  
test2 = "test2" 

by now I've solved the issue adding a input

<input type="text" name="useless" value="useless"> 

so all info in the POST is correct, and the bad result ("uselePr")  happens on a INPUT that I'm not using.

Comment 1

8 years ago
to solve it by now, the input type I add s

<input type="hidden" name "useless" value="useless">

instead of 

<input type="text" name="useless" value="useless"> 

this problem also happens in "hidden" fields.
Does the problem also happen with Firefox 3.5 beta4
(ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.5b4), and/or
with recent Shiretoko or Minefield nightlies

Can you attach a testcase that demonstrates this problem, or post a
URL to a testcase?

Comment 3

8 years ago
I can confirm that this happens to me as well up to 3.0.13 with OS 10.5.8 on a G5 (PPC) Mac This is what I found.

1. Looking at firebug via the response headers tab, it thinks that the correct information was posted
2. Using a hub plugged directly into the back of the computer and wireshark I can confirm that the packet has the Pr characters in it.
3. According to wireshark the TCP checksum is good
4. I used a Unicode character and when it was translated to an encoded form only the last 2 hex characters were effected  so %26%23916%3B => %26%23916%Pr
5. GET requests are not effected
6. All other headers are fine
7. The request I have been doing are being done with x-www-form-urlencoded method.

After talking to some people in our district it does sound like this effects both PPC and Intel but I have not confirmed that yet.  They also say that it effects local user on the mac but not user accounts that login via the network (LDAP).  Once I confirm some of these I will post back here.

Here is a URL to a test case site:

Comment 4

8 years ago
Well I ran some more tests and here it is.

1. It does only effect local user accounts and not users logged into the mac via LDAP.  The accounts in question are limited users.  I have not tried an admin user.
2. It does not effect SSL.  The request comes through fine
3. It effects the final version of the post string ie if you have a text box encoded as "text1=a" it will translate to "text1Pr"
4. It effect Intel and PPC
5. It still effects Firefox 3.5.3!  (Have not tried the nightlies)

Comment 5

8 years ago
I think I found the source of the problem it looks like the problem is when you have Apple's parental controls enabled on the mac.  We created a new account with parental controls and it had the problem.  We disabled the controls on the account and it was fine.  Turing it back on made the problem re-appear.  Here are the steps to reproduce and test the problem.

1. Create a new user with parental controls enabled
2. Login and start firefox
3. Go to http://www.m1k0.net/test/inputtest.php
4. Enter "Hello" in the first box and "World" in the second
5. Click "Submit Query"

Expected result is the post string should be "text1=Hello&text2=World"
The actual result is the post string is "text1=Hello&text2=WorPr"

From searching the web this looks like it is a common issue even among other tools such as curl http://curl.haxx.se/mail/lib-2009-09/0169.html Now that I know what this is let me see if there is a known or previously existing bug in bugzilla.

Comment 6

8 years ago
I found (bug 411927) but there is no resolution there.

Some people on the apple forum talked here http://discussions.apple.com/thread.jspa?threadID=1427798 with not clear resolution besides disabling parental controls but there is a apple bug number 5831876.

This blog has some good info http://joeberkovitz.com/blog/2009/09/17/mac-os-x-parental-controls-stomp-the-web/

In the end this looks like a apple issue but I wonder if there is a solution like setting some flag on the HTTP connection to not filter/mangle the headers.

I think I reached the limit on what I can do here but if you want me to test something let me know.
Miko, thanks very much for your work on this!

I'm CCing some QA people to ask them to confirm what you've reported.

We need to know if this problem also happens in Safari.  If it does,
this is clearly an Apple bug that has nothing to do with Firefox, and
you should open a bug with Apple.

Even if it doesn't happen in Safari, it's probably still an Apple bug
-- though in that case we'll probably need to find a way to work
around it.

This bug may be related to bug 411927, but I don't think it's a
Summary: Form sent using POST replaces the value of the last two chars of the last input text with "Pr" → [OS X] Apple's parental controls replace last 2 chars of input text with "Pr" on POST
OK, I've now confirmed this myself.

I see the problem on OS X 10.5.8 in Firefox 3.5.3 and in today's
Minefield (trunk), Namoroka (FF 3.6) and Shiretoko (FF 3.5.X)
nightlies.  I don't see it in Safari.

However I don't see this problem on OS X 10.6.1.  Apparently Apple has
now fixed the problem there.  I'm not sure when/if they'll backport
their fix to 10.5.8.

You should open a bug with Apple and ask them :-)

Ever confirmed: true
Safari works fine on 10.5.8 and doesn't show this problem but with Firefox it's visible on all branches (1.9.1/1.9.2/trunk). On 10.6 everything is fine.

Miko, could you create a http log? That would be pretty helpful to identify if this is a problem on our side or Apple. I don't have time for that so we would really appreciate it.

Hardware: PowerPC → All
Summary: [OS X] Apple's parental controls replace last 2 chars of input text with "Pr" on POST → [10.5] Apple's parental controls replace last 2 chars of input text with "Pr" on POST
Miko, whatever you do, *don't* paste your log into a comment.  You'll need to "attach" it using "add an attachment" above.

I'll also be attaching a log.
Miko, don't bother posting a log following those instructions.  Even the most verbose log doesn't contain the *contents* of the http headers.

Comment 12

8 years ago
From what I gathered Apple uses Apache as a proxy for all HTTP connections and uses it to filter web pages.  So Firefox is not doing anything wrong directly except maybe making headers that Apple's version of Apache can't parse properly.  We are using a workaround that was mentioned on the apple forum I linked before that says to do

sudo chmod a-x /usr/sbin/httpd

We were not using the web features of the Parental controls just the time limits and application restriction features so that is valid for us.

As for the logs and HTTP headers I can give you some wireshark captures I have or the firebug header info.
> As for the logs and HTTP headers I can give you some wireshark
> captures I have or the firebug header info.

That would do very nicely.  I suppose wireshark logs would be best
(most complete).  But attach whatever kind of log you think is most
Created attachment 404749 [details]
Wireshark traces

Here are some Wireshark traces.  I frankly don't know what to make of
"Firefox 3.5.8" -> "Firefox 3.5.3"
Notice that the FF POST without parental controls enabled contains an
extra header:  "Keep-Alive: 300".

Anyone know what that could mean?
And the Safari POST with parental controls enabled contains an extra
header:  "Cache-Control: max-age=0"
Created attachment 404756 [details]
Firefox http trace

This trace (made with NSPR_LOG_MODULES=nsHttp:3) shows that Apple's
parental controls swallow Firefox's POST's "Keep-Alive: 300" header.
Lets move this bug to Core:Networking. Hopefully Biesi or Boris have an idea.
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Version: unspecified → Trunk
Idea about exactly what's buggy in Apple's proxy?  Sorry, no such luck.  The curl thread mentions the Expect header, but we don't send it.

Does someone want to change necko to not send the keep-alive header as and experiment and see whether that actually helps?
> Does someone want to change necko to not send the keep-alive header
> as and experiment and see whether that actually helps?

I tried this.  It doesn't help.

Even when FF doesn't send a Keep-Alive header, Apple's parental
controls still change the location of the "Connection: keep-alive"
header -- it gets moved to the very end of the list of headers (after
the Content-Type header).

So (on the face of it), Apple's 10.5.X parental controls often
(always?) mess up attempts to change Firefox's POST headers, but don't
mess up their attempts to change Safari's POST headers.  And the
parental controls can make gratuitous (unneeded) changes -- like
changing the location of the Connection header.

These are surely Apple bugs, but there doesn't appear to be anything
we can do about them.  It helps that the problems seems to be fixed on
OS X 10.6.X.
For the record, I tried changing FF's user-agent string to match Safari's -- this didn't help, either.
Another thought:  There may be some kind of parental controls API (possibly undocumented) that Safari uses, which FF doesn't.  So Apple's Apache proxy may not actually change Safari's POST headers -- Safari may send different headers depending on what the (presumed) parental controls API tells it.

Comment 24

8 years ago
I was playing around with the some more and this is very interesting.  It looks like when these control are enabled it may be impossible to directly access any of the servers on any of the standard web ports (80,443,8080).  Instead all those connects are redirected to the local machine.   Meaning you can establish a connection to non-existant address like  Once the proxy connects it will parse the Host part of the header then if you are allowed make a connection to the remote host.

As for finding why this happens I have been trying to use netcat to pass different headers to it but I can not replicate it even with the same headers that I captured that seem to cause the problem.  One odd thing is every time I used netcat to try to send custom headers I got some HTML saying 400 Bad request on the end of the correct output for the test page.

I also tested with opera and it does not have this problem.  So I am wondering if it is the way the TCP stream is constructed that the proxy is starting to pull the data before we are finished writing to the connection

Here is a possible work around (at least it is better then getting corrupt data and being lied to by the OS).  Enable the HTTP proxy and point it to the local proxy.  In my case it was 10010 I am not sure if that is standard or not.  When I use the manual proxy like that pointing to the local proxy it seems to work fine.  Though I would like to have a few more people try it to make sure.  If it does work maybe we should detect Parental controls and force the setting for all the ports that get redirect like 80,8080,etc.
Duplicate of this bug: 469637
Have we reported this bug to Apple?  That seems like the right way to go here instead of trying to reverse-engineer their brokenness.
> Have we reported this bug to Apple?

I haven't, and I suspect it wouldn't be worth the trouble:
Historically, Apple hasn't shown much interest in fixing bugs that
only exist in older major releases of OS X.

I'll try to find time to report this, sometime this week or next week.
But I won't be sad if someone beats me to it :-)
cc'ing some friends at apple, you know, just in case that might help this along.

Comment 29

7 years ago
I can tell you right now the OS update team is not going to be too interested in taking this if it is 10.5 only. I will ping them though.
Thanks, Christian - sucks, but good to know. Is there any way we can work around this? I'm assuming that it affects Firefox 3.6.x and Firefox 4 the same?
> I'm assuming that it affects Firefox 3.6.x and Firefox 4 the same?

Yes.  The STR from comment #5 still work exactly the same with today's
Minefield (FF 4), FF 3.6 and FF 3.5 nightlies.

> Is there any way we can work around this?

Not that I'm aware of.  But maybe someone from Apple can suggest a
>> Is there any way we can work around this?
> Not that I'm aware of.

Actually this isn't quite true.  Miko came up with a partial
(user-level) workaround in comment #12, and a more comprehensive one
in comment #24.

But I don't know enough about our networking support to say whether or
not the approach from comment #24 is reasonable/feasible for us.

It would still be best if someone from Apple could give us hints about
a simpler way to work around this bug.
this appears to be only an os x 10.5 issue.. so as its really just a compat thing and hasn't been bugging people to the point of duping this bug for years - wontfix.
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.