Last Comment Bug 489575 - [10.5] 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"...
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: All Mac OS X
: -- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
local intranet website
: 469637 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-22 07:38 PDT by Miquel Botanch
Modified: 2015-12-17 11:32 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Wireshark traces (11.06 KB, text/plain)
2009-10-05 19:16 PDT, Steven Michaud [:smichaud] (Retired)
no flags Details
Firefox http trace (761 bytes, text/plain)
2009-10-05 20:06 PDT, Steven Michaud [:smichaud] (Retired)
no flags Details

Description Miquel Botanch 2009-04-22 07:38:30 PDT
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 Miquel Botanch 2009-04-27 15:22:13 PDT
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.
Comment 2 Steven Michaud [:smichaud] (Retired) 2009-04-30 10:38:27 PDT
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
(ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly)?

Can you attach a testcase that demonstrates this problem, or post a
URL to a testcase?
Comment 3 Miko Brown 2009-10-04 13:47:04 PDT
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:
http://www.m1k0.net/test/inputtest.php
Comment 4 Miko Brown 2009-10-05 07:38:37 PDT
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 Miko Brown 2009-10-05 11:08:48 PDT
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 Miko Brown 2009-10-05 11:31:36 PDT
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.
Comment 7 Steven Michaud [:smichaud] (Retired) 2009-10-05 11:50:08 PDT
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
duplicate.
Comment 8 Steven Michaud [:smichaud] (Retired) 2009-10-05 12:49:53 PDT
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 :-)

http://bugreporter.apple.com/
Comment 9 Henrik Skupin (:whimboo) 2009-10-05 13:05:33 PDT
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.

https://developer.mozilla.org/en/HTTP_Logging
Comment 10 Steven Michaud [:smichaud] (Retired) 2009-10-05 13:20:14 PDT
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.
Comment 11 Steven Michaud [:smichaud] (Retired) 2009-10-05 13:36:23 PDT
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 Miko Brown 2009-10-05 14:12:26 PDT
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.
Comment 13 Steven Michaud [:smichaud] (Retired) 2009-10-05 14:20:40 PDT
> 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
appropriate.
Comment 14 Steven Michaud [:smichaud] (Retired) 2009-10-05 19:16:45 PDT
Created attachment 404749 [details]
Wireshark traces

Here are some Wireshark traces.  I frankly don't know what to make of
them.
Comment 15 Steven Michaud [:smichaud] (Retired) 2009-10-05 19:19:54 PDT
"Firefox 3.5.8" -> "Firefox 3.5.3"
Comment 16 Steven Michaud [:smichaud] (Retired) 2009-10-05 19:39:13 PDT
Notice that the FF POST without parental controls enabled contains an
extra header:  "Keep-Alive: 300".

Anyone know what that could mean?
Comment 17 Steven Michaud [:smichaud] (Retired) 2009-10-05 19:47:41 PDT
And the Safari POST with parental controls enabled contains an extra
header:  "Cache-Control: max-age=0"
Comment 18 Steven Michaud [:smichaud] (Retired) 2009-10-05 20:06:36 PDT
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.
Comment 19 Henrik Skupin (:whimboo) 2009-10-06 00:29:23 PDT
Lets move this bug to Core:Networking. Hopefully Biesi or Boris have an idea.
Comment 20 Boris Zbarsky [:bz] 2009-10-06 07:42:30 PDT
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?
Comment 21 Steven Michaud [:smichaud] (Retired) 2009-10-06 10:22:50 PDT
> 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.
Comment 22 Steven Michaud [:smichaud] (Retired) 2009-10-06 10:23:46 PDT
For the record, I tried changing FF's user-agent string to match Safari's -- this didn't help, either.
Comment 23 Steven Michaud [:smichaud] (Retired) 2009-10-06 10:52:08 PDT
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 Miko Brown 2009-10-06 18:32:42 PDT
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 1.1.1.1.  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.
Comment 25 Mike Beltzner [:beltzner, not reading bugmail] 2010-09-20 11:55:23 PDT
*** Bug 469637 has been marked as a duplicate of this bug. ***
Comment 26 Boris Zbarsky [:bz] 2010-09-20 12:06:35 PDT
Have we reported this bug to Apple?  That seems like the right way to go here instead of trying to reverse-engineer their brokenness.
Comment 27 Steven Michaud [:smichaud] (Retired) 2010-09-20 12:28:52 PDT
> 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 :-)
Comment 28 Mike Beltzner [:beltzner, not reading bugmail] 2010-09-20 13:43:01 PDT
cc'ing some friends at apple, you know, just in case that might help this along.
Comment 29 christian 2010-09-20 13:52:12 PDT
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.
Comment 30 Mike Beltzner [:beltzner, not reading bugmail] 2010-09-20 14:58:11 PDT
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?
Comment 31 Steven Michaud [:smichaud] (Retired) 2010-09-20 18:13:05 PDT
> 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
workaround.
Comment 32 Steven Michaud [:smichaud] (Retired) 2010-09-20 18:29:35 PDT
>> 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.
Comment 34 Patrick McManus [:mcmanus] 2015-12-17 11:32:27 PST
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.

Note You need to log in before you can comment on or make changes to this bug.