What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 134 Stack Exchange communities.

Why did SO decide to use Markdown sharp? It seems that a better idea would be to get both the HTML and the markdown from the client-side WMD. This way there would be no incompatibilities between two implementations, at the expense of having to store both in the DB.

share|improve this question
    
FYI: The two should never differ: meta.stackexchange.com/questions/1227/… –  The Unhandled Exception Mar 10 '10 at 17:59
    
@Josh: Exactly. So why have two implementations? That can only lead to incompatibility. After reading the responses, I'm starting to think they should use showdown server-side too. –  Paul Biggar Mar 11 '10 at 20:45

4 Answers 4

up vote 10 down vote accepted

And then what do you do when people have javascript disabled?

Note, XSS protection is completely unrelated to Markdown support, even though it is super important. The typical XSS protection function has the following sig: string protect(string) you could run the protection against the mystical submit markdown AND html implementation, which as pointed by me would completely fail if javascript is disabled.

So ... to recap.

If you posted both html and markdown to the server:

  1. Your payload would be bigger (not that important)
  2. You lose javascript off support for posting content.
  3. If a web browser has a slightly broken javascript system that fails with showdown.js, you would also be screwed.
  4. Malicious users would be able to make it really annoying to diagnose issues.
share|improve this answer
4  
vbscript perhaps? –  Antony Mar 9 '10 at 23:23
1  
@Antony: that was sarcasm, right ;-) –  ChristopheD Mar 9 '10 at 23:32
    
and then what do you do when... –  jmfsg Mar 9 '10 at 23:32
    
@christoped - no, why? :-p –  Antony Mar 9 '10 at 23:38
1  
As-is, the site barely functions without javascript. I can't vote, comment or post. There's a big warning at the top that the site works best with javascript enabled. –  The Unhandled Exception Mar 9 '10 at 23:59
    
You can actually post... Just have to deal with a very annoying CAPTCHA system first. –  Shogging through the snow Mar 10 '10 at 0:12
1  
Josh: You can read and post, or in other terms, you can Ask and Answer questions. So all the basic functionality of Q&A site work without JavaScript, which was the goal. –  Michael Stum Mar 10 '10 at 1:10
1  
Yes, I can't understand the XSS posts, its orthogonal. (BTW, the first time one reads your post you sound crazy, but I guess you're replying to the other posts as well as the question). –  Paul Biggar Mar 10 '10 at 1:58
    
If the user has no JS, then they haven't seen a preview, so there is only markdown, and so no incompatibility problems. I think would deal with 2 and 3. I guess this means you do need a server side implementation however (though it could easily use showdown in this case). 1 is not hugely important as you say. 4 could be an issue, but it might not even occur (and its not a vulnerability). –  Paul Biggar Mar 10 '10 at 2:01
    
I do agree. This is suggesting the anti-thesis to software efficiency. –  Robert Mallow Nov 16 at 23:17

And then what do you do when people sends you malformed/XSSed content?

<post site="stackoverflow" class="answer"> You can never trust the user input, you have to check it server-side, and you have to check it on the client to improve responsiveness. You can't avoid duplication of code (unless you are using server-side javascript). </post>

share|improve this answer
1  
I'd +10 if I could. –  The Unhandled Exception Mar 9 '10 at 23:55
3  
Though important, just because you decided to take in html and markdown from the users, does not preclude you from running XSS protection algorithms over it. –  waffles Mar 10 '10 at 0:39
    
Well of course you check them. I don't see how this answers the question. –  Paul Biggar Mar 10 '10 at 1:52

While there would be no incompatibilities (since there would then only be one [someone can feel free to insert a Highlander pic/joke here]), there would also be no markdown for those with scripting disabled (as pointed out by waffles) and there would be less protection from malformed content.

share|improve this answer
    
"less protection from malformed content" -- read: "no protection from malformed content" –  The Unhandled Exception Mar 9 '10 at 23:54
1  
You can't already post without javascript. The anti spamming measures don't allow you IIRC. –  perbert Mar 9 '10 at 23:54
    
@voyager: yeah, you can. The CAPTCHA is much more annoying without JavaScript, but it can be done... –  Shogging through the snow Mar 10 '10 at 0:10
    
@Josh: why would there be no protection? I'm not suggesting just putting the data in the DB without validating. –  Paul Biggar Mar 10 '10 at 1:53
    
@Paul: how are you going to validate the Markdown without regenerating it and comparing? –  The Unhandled Exception Mar 10 '10 at 1:58
    
@Josh: You don't need to validate that its the same, just that there's no malformed tags/HTML/XSS etc. It hardly matters if their markup doesn't match the HTML. –  Paul Biggar Mar 10 '10 at 17:44
    
@Paul: But then I can send any HTML I want, even it it's not valid markdown HTML, which defeats the point of using Markdown (in my opinion). In other words it means I could potentially post HTML which would not otherwise be able to be generated using Markdown. –  The Unhandled Exception Mar 10 '10 at 17:54
    
@Josh: Whatever is sent must be validated. The problems you raised must be handeld by validation. So in this case, it must not be an illegal tag. –  Paul Biggar Mar 11 '10 at 20:40

I really feel that @voyager's answer is the best one, but I think you hit on a valid point in your own question:

This way there would be no incompatibilities between two implementations

In my opinion, if there's incompatibilities between the two implementations then the client side one is wrong. This is because the server is ultimately the system which sanitizes and stores the data. I have read (but can't recall now -- someone please comment with a link?) posts on meta explaining why certain parts of Markdown don't work right client side due to the limitations of the client side logic. Thus, the server side is the "correct" way and can't be done away with.

But ultimately, @voyager is right, you can never trust user input!

share|improve this answer
    
The server side can't be the right implementation. The client side is what the user tried to write, and therefore expects to see. IF the server side differs, it would make no sense to choose the server side. Which on is actually at fault and needs to be fixed in that case is a different question however. –  Paul Biggar Mar 10 '10 at 1:55
    
In my opinion the client side is a preview. The server side is the real deal. But, we have differing opinions :-) –  The Unhandled Exception Mar 10 '10 at 2:04
    
Why is the server side the real deal? The user wrote the content with the preview, so anything that differs wont be what the user expected. It seems you are taking a dogmatic approach to it ("the server is always right"). –  Paul Biggar Mar 10 '10 at 17:46
    
@Paul: You're right, I probably am being a bit dogmatic. I'm saying the server is always right because the server is under the control of the SOFU developers and is in control over what gets posted to the database, and in control of generating HTML for the user to see. It's the ultimate authority because it powers the whole site... I'm not sure if I'm explaining myself clearly; however I do understand your point of view as well. –  The Unhandled Exception Mar 10 '10 at 17:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .