Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Vote for the Mozilla bug that is screwing K5! (Or Not)

By edibiase in MLP
Wed Nov 08, 2000 at 03:23:44 PM EST
Tags: Kuro5hin.org (all tags)
Kuro5hin.org

Mozilla M18 has a bug. A bug that is so hideous, so ugly, and so infused with pure evil that it causes submissions to Kuro5hin to be formatted incorrectly! Obviously, this bug must be stopped at all costs. So help us to fix it! Vote for bug #59456 in the Mozilla bug-tracking system, and you'll be helping to make sure that Kuro5hin works for users of all browsers, which is certainly a noble cause.

[editor's note, by Inoshiro] Blame me for the title, I came up with it :) Hopefully if we all vote for this bug, it can be fixed before rusty goes mad and breaks Scoop in an effort to work around it.

Update [2000-11-8 17:9:48 by rusty]: It's not a Mozilla bug. It was a Scoop bug. I suck. Please leave the nice people at Mozilla alone. :-)


Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Scoop
o Kuro5hin
o Mozilla
o a bug
o Vote
o Also by edibiase


Display: Sort:
Vote for the Mozilla bug that is screwing K5! (Or Not) | 12 comments (10 topical, 2 editorial, 0 hidden)
Quick fix (3.50 / 6) (#1)
by J'raxis on Wed Nov 08, 2000 at 02:33:10 PM EST

Here's a little quick fix:

if ($ENV{HTTP_USER_AGENT} =~ /Mozilla.*m18.*Gecko/i) {
  $yourFieldVariable =~ s/\\(['"])/$1/g;
}

Note: If you used PHP, it has a stripslashes() function that does this for you. PHP escapes form fields (at least when you're using the $HTTP_POST_VARS or $HTTP_GET_VARS hash) in the same manner as M18 seems to.

-- The Perl-coding Raxis

[ J’raxis·Com | Liberty in your lifetime ]

This sort of hackery... (4.00 / 7) (#6)
by trhurler on Wed Nov 08, 2000 at 03:16:02 PM EST

is why some people shouldn't be given keyboards. You do NOT write code to work around bugs. You fix the damned bugs. I realize this isn't always possible in commercial software, but we're talking about MOZILLA. Yes, you're clever. Yes, your idea would "work." And yes, it is the worst idea I've seen in a long time; code like this clutters up a program and ten years from now, nobody will have any clue why it is there - so they'll leave it there, "just in case." Your clever little hack will become an immortal ugliness because it was easier and quicker than doing the right thing. That's stupid.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
comment it, silly! (3.80 / 5) (#7)
by plastik55 on Wed Nov 08, 2000 at 03:40:49 PM EST

code like this clutters up a program and ten years from now, nobody will have any clue why it is there - so they'll leave it there, "just in case." Your clever little hack will become an immortal ugliness because it was easier and quicker than doing the right thing. That's stupid.

You put a comment next to those three lines of code saying "Mozilla, as of 2000/11/8, has a bug--it escapes quotation marks in form submissions when it's not supposed to."Does that not tell everyone ten years from now what the code's doing?

When in doubt, one line of comment per line of code.

Furthermore, I'm still not convinced that the bug actually is a bug--I know(for example) that spaces are supposed to be escaped with %20 when they are sent with URLs, so they aren' t mangled in transit. Perhaps this is a similar situation.
w00t!
[ Parent ]

Well... (3.33 / 3) (#9)
by trhurler on Wed Nov 08, 2000 at 04:35:19 PM EST

You put a comment next to those three lines of code saying "Mozilla, as of 2000/11/8, has a bug--it escapes quotation marks in form submissions when it's not supposed to."Does that not tell everyone ten years from now what the code's doing?
It might, if anyone even knows what Mozilla is ten years from now. You will gain an appreciation for this problem the likes of which you never imagined possible the day you are assigned by your boss to modify, maintain, rewrite, or even just comprehend some 20 or 30 year old code. Even if well commented, half the references in the comments will be things nobody knows about anymore, and the other half will be things that have changed so much that in the present day context they don't make sense. That doesn't mean you shouldn't write code, but it does mean that you should have a better reason than "quick spot fix so I can get this working today instead of tomorrow."
Furthermore, I'm still not convinced that the bug actually is a bug--I know(for example) that spaces are supposed to be escaped with %20 when they are sent with URLs, so they aren' t mangled in transit. Perhaps this is a similar situation.
There is a well defined list of characters which must be escaped in urls in the appropriate RFC. Upon checking it I find that, indeed, quotes are supposed to be escaped in URLs. What I'm not certain of is whether Mozilla is doing this properly or accidentally quoting quotes that actually delimit URL components, which latter behavior is simply out and out wrong. I voted for the bug because at the least, someone at Mozilla needs to look at the issue closely and decide whether it is a real bug or not.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
I got a suggestion for ya... (2.40 / 15) (#4)
by ribone on Wed Nov 08, 2000 at 02:39:42 PM EST

Call me a troll, but hey, why not use something else? I've given up (and I know I'm not the only one)on Mozilla, though at one time I was a staunch supporter of it. I believed in it, then they had to try and market an entire, useless platform to me. I refuse to condone the crap that they've done with the whole idea and think it should be either restarted or scrapped entirely.

Just my $0.02

A dumb question... (3.33 / 3) (#5)
by Maniac on Wed Nov 08, 2000 at 03:11:51 PM EST

What does the standard say about this situation?

I read the bug description and if its a standard violation it should be fixed. If its not, then the server must be fixed. I can't tell from the description above or from the bug report which case it is. I've seen several cases where code generates stuff like %20 for spaces to pass them through the hostile internet. In those cases you WANT the substitution.

Of course, I'm submitting this with Communicator 4.74, not Mozilla, so I don't have as much interest in a fix.... :-<.

There is no standard. (4.50 / 2) (#8)
by Inoshiro on Wed Nov 08, 2000 at 04:16:24 PM EST

There's just a de-facto standard. Mozilla's behaviour is different from all other browsers. Because of this, it's causing problems for those of us used to the standard behaviour. It shouldn't try to outsmart the user, I think.



--
[ イノシロ ]
[ Parent ]
Too busy to look...BUT (3.00 / 3) (#10)
by Maniac on Wed Nov 08, 2000 at 05:11:46 PM EST

I can't spend a long time looking, but I can't believe there is NO standard on this issue. There's an applicable standard on EVERYTHING on the Internet. To quote from RFC 2616 (which I believe IS relevant in this case)...

4.3 Message Body

The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding header field (section 14.41).

message-body = entity-body | <entity-body encoded as per Transfer-Encoding>

Transfer-Encoding MUST be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding is a property of the message, not of the entity, and thus MAY be added or removed by any application along the request/response chain. (However, section 3.6 places restrictions on when certain transfer-codings may be used.)

The rules for when a message-body is allowed in a message differ for requests and responses.

The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request’s message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code (section 6.1.1). All responses to the HEAD request method MUST NOT include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length.

The message body must be encoded with the transfer encoding specified (whatever that is). They don't get to add any extra (or less) stuff than what that spells out. It could be the encoding method Mozilla uses isn't supported in the tools you are using. If they don't specify a transfer encoding & the standard doesn't specify other rules (i.e., HTML does for special characters) then you are in the right. But from what you've posted, I can't tell.

Re: RFC 2616 (none / 0) (#12)
by dice on Thu Nov 09, 2000 at 09:08:27 PM EST

I'm currently in the process of trying to write a web server.

I just wanted to comment on how poorly rfc 2616 rates against other RFCs. Take a drill to my head, turn it on high power, and once you break through, turn it on a lower power, and it'll swirl my brains around.

Thank you.

[ Parent ]
More Info (5.00 / 6) (#11)
by rusty on Wed Nov 08, 2000 at 05:16:20 PM EST

This, as I mention above in the story, as after all a Scoop bug. And I feel like the world's biggest asshole for blaming it on them. In fact, Mozilla appears to be the only browser that handles form input *right* now that I know what the problem was.

What happened was, for utterly crack-addled reasons I'm still not clear about, Scoop was translating " to &quot; when you previewed a comment. Every other browser took the &quot; entity and rendered it as " in the textarea, so when you hit submit again, after previewing it, it submitted a literal " character.

Mozilla, however, kept the &quot; and though rendering it as a ", submitted it back as an &quot;. Ok, I'm not sure if this is right or not-- to show one thing and submit another. But from one point of view, Mozilla was simply submitting *exactly* what was in the form.

This issue should be fixed now. Please let me know if you still suffer problems like this.

And I apologize to the Mozilla team for publically haranguing them about this for so long. Thirty lashes for me.

____
Not the real rusty

Vote for the Mozilla bug that is screwing K5! (Or Not) | 12 comments (10 topical, 2 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!