The URL, http://search.yahoo.com/bin/search?p=akamait , does not work in Mozilla Build ID: 2002041903 (0.9.9+) trunk Windows 98. Another way to reproduce the problem is to go to http://www.yahoo.com and search for akamait . The search works on IE 6. Mozilla can search for akamait on Google. Expected results: Mozilla opens the URL. Actual results: Mozilla does not open the URL
confirming linux build from this morning pretty weird os -> all
OS: Windows 98 → All
this works if you set HTTP to 1.0 breaks if you set HTTP to 1.1
Confirming that. Adjusting component and summary.
Component: Browser-General → Networking: HTTP
Summary: Mozilla can't search for "akamait" on Yahoo → Using HTTP 1.1, Mozilla can't search for "akamait" on Yahoo
Maybe somebody should set Mozilla's user-agent property to whatever Internet Explorer uses and see if the search suddenly works.
WFM on XP, 2002041603, HTTP1.1, so it's a recent regression if so.
This is broken in RC1, so its not related to the piplining stuff We send the http/1.1 request, and the server returns an http/1.0 response with a 302, no content length, and some data. The connection is clsoed, and we don't do anything. With 1.1, we follow the 302 - the server's response is the same. The only difference is that with 1.0, we send connection: close Darin: Why is http/1.0 disabling persistent connections? HTTP/1.1 with persistent connections disabled doesn't work, though.
reassigning to darin probably helps, too.... Darin: see previous comment.
Assignee: Matti → darin
Severity: normal → major
QA Contact: imajes-qa → tever
> Maybe somebody should set Mozilla's user-agent property > to whatever Internet Explorer uses and see if the search > suddenly works. I did. It suddenly worked. It must be Yahoo doing some weird stuff (not the first time...). I use "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417".
No, AFAICS, the response from the webserver is perfectly valid. Theres something else going on. yahoo is top100
There is a slight difference in the body of the response between Mozilla and IE user agents. Seems like the Mozilla response is slightly corrupted by Yahoo maybe? Look how the 'encoded' is somehow mangled. HTTP/1.0 302 Found Date: Sun, 21 Apr 2002 18:40:50 GMT Location: http://google.yahoo.com/bin/query?p=akamait Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 The document has moved <A HREF="http://google.yahoo.com/bin/query?p=akamait">here</A>.<P> <P>Additionally, a 302 Found error was enco3b hile trying to use an ErrorDocument to handle the request. 0
Ooh. didn't notice that. Yeah, the chunked encoding looks wrong. Hmmm. Should we care about that for redirection responses? Why are we spending time parsing it anyway? I guess we have to, to find the end... What is the response with ie, then?
Summary: Using HTTP 1.1, Mozilla can't search for "akamait" on Yahoo → Using HTTP 1.1, Mozilla can't search for "akamait" on Yahoo
Don't know if this helps, but it works through a HTTP 1.1 proxy (squid). Without the proxy, it doesn't work. This is with 2002041711 (1.0 RC1) on WinME.
i only can use proxy,so i can not reproduce this bug.:-(
Same thing happens with "akamaite", "akamaitec", "akamaitech", "akamaitechn", "akamaitechno", "akamaitechnol", "akamaitechnolo", "akamaitechnolog", "akamaitechnologi". Also happens if you append various punctuation marks, like commas and periods, to any of the above. Interestingly enough, it doesn't happen with any _shorter_ substrings, like "akamai", "akama", etc. So, it only happens with substrings of length 7 - 16 characters, of the string "akamaitechnologies".
If, from www.yahoo.com, you click on "advanced search", then enter "akamait" in the text box on that page, the same thing happens. HOWEVER, if you choose something other than "Yahoo!" from the pull-down menu, it works fine.
in linux build 2002042021, i'm able to repro this problem. if i switch to HTTP/1.0, then it works fine. bbaetz: it is still using keep-alive connections... i don't see us sending "Connection: close". this looks to me like a server bug. what the heck is it doing sending a Transfer-Encoding: chunked in a HTTP/1.0 response?! i'm tempted to send this over to evangelism.
here's what i get from a telnet session: <telnet> src> telnet search.yahoo.com 80 Trying 22.214.171.124... Connected to search.yahoo.com. Escape character is '^]'. GET /bin/search?p=akamait HTTP/1.1 Host: search.yahoo.com HTTP/1.0 302 Found Date: Wed, 24 Apr 2002 05:31:24 GMT Location: http://google.yahoo.com/bin/query?p=akamait Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 The document has moved <A HREF="http://google.yahoo.com/bin/query?p=akamait">here</A>.<P> <P>Additionally, a 302 Found error was enco3b hile trying to use an ErrorDocument to handle the request. 0 </telnet> notice that the chunked body is malformed. there is no length indicator for the first chunk. one solution to this problem would be to ignore Transfer-Encoding header if the response is HTTP/1.0. that would be fairly simple and would do the trick here since the server has sent a Connection: close header. other than that, i can't think of a decent work around for this fck'd server. -> mozilla 1.0
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.0
Created attachment 80745 [details] [diff] [review] v1 patch this patch makes us ignore a Transfer-Encoding header if the response is HTTP/1.0
bbaetz: can you please r= this patch? thx!
This looks like a high-risk change just to support one broken server/load-balancer. Is it the right thing to do for standards compliance? If not, perhaps evangelism would be better... ?
Why can't a 1.1 server send a chunked encoding? Our request advertises that we support it.... Comment 8 suggests that changing the useragent to ie makes us work. Is this the case? I'm still tempted to send this to evangalism. However, what about this: For a 302 response, do we need to decode the content? In theory, we need to do so to find the end of the connection. For chunked we do, but why bother gzipping stuff. Can't we just treat invalid content in a 3xx series response as wanting us to close the connection? And if we get a connection: close, do we even need to do that? Wouldn't that be faster. Or do we show this content in some case (like if the site we're reditected to doesn't exist, or something)?
> Why can't a 1.1 server send a chunked encoding? Our request advertises that > we support it.... i assume you mean 1.0 server... > For a 302 response, do we need to decode the content? In theory, we need to > do so to find the end of the connection. For chunked we do, but why bother we need to find the end of the transaction to support keep-alives and pipelining. > gzipping stuff. Can't we just treat invalid content in a 3xx series response we don't handle "Transfer-Encoding: gzip" here... it'd be handled by the channel if we ever needed to display the message body. > as wanting us to close the connection? And if we get a connection: close, do > we even need to do that? Wouldn't that be faster. Or do we show this content > in some case > (like if the site we're reditected to doesn't exist, or something)? we could ignore a Transfer-Encoding header if the server sends "Connection: close" ...that would work. i'm happy to reassign this to evangelism, but it just seems odd to handle a chunked response from a HTTP/1.0 server. a HTTP/1.0 server presumably knows nothing about chunked encodings. maybe it just picked up the header accidentally... via some other interal server or whatever, which is what i suspect is going on here. so, this patch is perfectly conformant with the HTTP standards, and it is very low risk IMO. that said, when i originally wrote this code, i wanted to make mozilla as flexible as possible. e.g., as bradley said, why shouldn't mozilla accept a chunked response from a HTTP/1.0 server... afterall, mozilla did say it supports chunking, right? that's a good argument IMO. so, i'm not really sure at this point what would be best for mozilla. maybe we should just shove this off to evangelism :-/ as far as the useragent string is concerned, maybe they generate junk for any unknown useragent?! i don't know... cuz when i just connected to the server via telnet, and issued a simple request (w/o specifying a User-agent header, i still got the same junk sent to mozilla).
We send an HTTP/1.1 request, and we get back an HTTP/1.0 response with a Transfer-encoding header. The header would work in a 1.1 response. In 1.0, though, it is not well formed. The strangeness causes us to not accept the response. In this case, however, we should try to accept it. Under the robustness principle, RFC 791, http://www.faqs.org/rfcs/rfc791.html , we should be conservative with what we send out, and liberal with what we receive. See also RFC 2145. The robustness principle would support accepting the response.
on that note... -> Tech Evangelism
Assignee: darin → doron
Status: ASSIGNED → NEW
Component: Networking: HTTP → US General
Product: Browser → Tech Evangelism
QA Contact: tever → zach
Target Milestone: mozilla1.0 → ---
Version: other → unspecified
The header works, the problem is that the content is invalid. If this were a widespread problem, I'd support the patch, but it sounds like someone at yahoo.com just forgot to print out the size of the first chunk. So yeah, TE should handle it.
Today, with 1.0 RC2 branch Build ID: 2002050106 Windows 98, it works. Don't know if the site changed or if Mozilla changed. Resolving worksforme.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Although the problem no longer occurs with "akamait", it still occurs with "akamaite", "akamaitec", "akamaitech", and so on, up to "akamaitechnologi". See what I originally said in comment #14. I'm reopening the bug. Sorry.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Using HTTP 1.1, Mozilla can't search for "akamait" on Yahoo → Using HTTP 1.1, Mozilla can't search for "akamaite" on Yahoo
Somewhat ironically, "akamai" is Hawaiian for smart, intelligent.
Similar problem occurs if you try to click on "Real Estate" (in the "Shop" line) on Yahoo's main page. The URL it links to is www.yahoo.com/r/r1, but when you click it, the same sort of thing happens. Thanks to Jim Reynolds for pointing this out. He also says it works with HTTP 1.0 but not HTTP 1.1
This is a more serious issue, that you can't use the "Real Estate" link on Yahoo. If the root cause of this problem is indeed the same as the cause of the "akamaite" searching problem, Tech Evangelism would find it easier to convince Yahoo to look into this problem.
Summary: Using HTTP 1.1, Mozilla can't search for "akamaite" on Yahoo → yahoo.com - Using HTTP 1.1, Mozilla can't search for "akamaite" on Yahoo
don't see it..
*** Bug 162702 has been marked as a duplicate of this bug. ***
*** Bug 162619 has been marked as a duplicate of this bug. ***
i'm a yahoo employee and notified the powers that be about this error. there was a problem with the search servers and it appears to have been fixed. it also looks like the real estate link works now. this has been tested on my bulid 2002081603. i have http 1.1 networking on.
I can confirm that this bug is fixed. Marking as such.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
Thank you and congratulations to Kelly Hirano and the Yahoo! team for the fix!
I'm reopening this bug, since it also affects the international sites, like Yahoo.ca, and they haven't been fixed. Users in Canada are unable to search for text that does not appear in the Yahoo directory. Hopefully we can get this fixed so my girlfriend can keep using Mozilla to search, and I don't have to keep hearing about how IE is better because Mozilla can't search... (Adding email@example.com to the cc: list, since he works for Yahoo)
it seems to work for me on my mac using the mozilla 1.1 build (Gecko/20020826). also seems to work on my win2k box running the same version. so this http://ca.search.yahoo.com/search/ca?p=akamaite&y=on url works for me. can someone else confirm?
I can confirm that the URL works, however the word "akamaite" is now in the directory. oeone is not in the directory, so the URL: http://ca.search.yahoo.com/search/ca?p=oeone&y=on does not work.
Summary: yahoo.ca - Using HTTP 1.1, Mozilla can't search for "akamaite" on Yahoo → yahoo.ca - Using HTTP 1.1, Mozilla can't search for "oeone"
I had been experiencing this problem with yahoo.ca for some time but chalked it up to a release 1.0 Mozilla (it worked in Netscape 4.72 so...). When 1.1 came out and I had the same problem, I searched and found this bug report. I have mailed (and I *mean* snail-mailed) Yahoo!Canada a letter informing them of the problem, letting them know it was their server (and that it was fixed already in the US), pointing them at the URL for bug 138869, and asking them to please let me know if and when they are going to fix it. Their only contact information was a physical mailing address in Toronto. Ugh! Bang those rocks together folks! Please let me know if anyone wants a copy of the letter (PDF) for posterity or information.
Maybe Kelly Hirano can help evangelise this to the international Yahoo sites. I can confirm that it is still broken for Yahoo.ca if you search for "oeone".
*** Bug 170286 has been marked as a duplicate of this bug. ***
Still affects kr.yahoo.com (bug 170286) and presumably other international sites.
Summary: yahoo.ca - Using HTTP/1.1, Mozilla can't search for "oeone" → yahoo (not .com) - Using HTTP/1.1, Mozilla can't search for "oeone"
removing topembed kw since it's an evangelism issue. replicated problem on ca.yahoo.com in 11/20 commercial branch. Doron please see what the problem is. Search button seems to be dead.
Priority: P2 → P1
I just noticed that I can go to the URL in the bug summary it works fine, but if I go to the Yahoo.ca page directly and type in "oeone" and then click on the search button, nothing happens. Therefor removing http://ca.google.yahoo.com/bin/query_ca?p=oeone URL from the bug.
kr and ca are the only ones I could find that are affected.
With the new yahoo page that seems to have gone up last night with a "Christmas" theme, Chimera can no longer search anything. You get a page that says no search terms were entered. Mozilla works fine.
could someone sum up what yahoo would have to fix so we can communicate to them? If I understand correctly, our HTTP/1.1 request gets a HTTP/1.0 response with a malformed Transfer-encoding header (Transfer-Encoding: chunked). What should the correct one look like? thanks!
HTTP 1.0 does not define transfer-encoding header and so it is illegal to use chunked transfer encoding header with this version. So, 1. They should correct the HTTP version to 1.1 when sending this header, and if so, the chunked encoding should follow the correct syntax as defined here: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2616.html#sec-3.6.1 or 2. They should not use chunked transfer encoding when using HTTP 1.0.
I don't see this problem with yahoo.co.jp.
I think I've fixed this for Y! Canada. Let me know otherwise.
I can confirm that. With Phoenix 0.5, I can now search for "oeone" from the Yahoo! Canada page. If there are no known problems anymore, let's close this bug.
resolved fixed, go susie.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 15 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Reopening the bug... This is still happening for kr.yahoo.com
I've sent the answer to one of their engineers. should be fixed shortly
Well I don't know if this is related to this bug or not... But when I go to www.yahoo.com initiate a search it completes fine. But when I click on next (to continue looking at search hits) I get connection refused when attempting to contact rd.yahoo.com. This is a rather recent occurence.
I just tested 'oeone', 'BitchX' etc., and all results are fine :). Tested keywords: - oeone - BitchX, itch, tchx and bitc - akamait I think you could remove 'Yahoo Korea' from the list now. Thanks,
Oops! I'm sorry I was confused something...(http 1.0) Yahoo Korea is still remained trouble site on this bug. Sorry for confusing you.
Finally, I could search "BitchX" through 'Yahoo Korea' with http 1.1 mode. I think 'Yahoo Korea' could be removed from this title. I used Mozilla(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030205) at http 1.1 mode and following keywords: - oeone - BitchX, itch, tchx and bitc - akamait Thanks even though I don't know who did it! p.s.) You could get 'no results' page of yahoo Korea with 'akamait' :-). http://kr.softwise.yahoo.com/bin/query?p=akamait
Searching for oeone on kr.yahoo.com still does not work for me using Mozilla 1.2.1 on RH 8.
I'm using Mozilla 1.3b(20030205 build) as I mentioned. I can get searching result with "oeone " in kr.yahoo.com. --- Then, Mozilla team deserve my thanks for fixing this problem. :-)
There are no issues left to resolve here. Yahoo has fixed the problem. Resolving as fixed. Thank you to the Yahoo team.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago → 15 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.